whalibmob 5.5.77 → 5.5.80

package/lib/messages/MessageSender.js

@@ -693,52 +693,50 @@ class MessageSender {
     // they simply omit the device-identity node (server accepts this for primaries).
     const allowPkmsg = true;
 
-    // First, run the phone-based usync (and own devices) in parallel.
-    // IMPORTANT: _pnToLid may be empty RIGHT NOW but gets populated during this
-    // await — incoming messages from the recipient (which arrive while we wait
-    // for the usync timeout) tell us their LID JID via from=LID + sender_pn attrs.
-    // We therefore check _pnToLid AFTER this await, not before.
+    // Enumerate the recipient's devices and our own in parallel — Baileys does
+    // the same in one getUSyncDevices([senderIdentity, jid]) call.
     const [_recipientDevicesByPhone, ownDevices] = await Promise.all([
       this._devMgr.bulkEnsureSessions([recipientPhone], this._signal, allowPkmsg),
       this._devMgr.ensureOwnDeviceSessions(ownPhone, this._signal, allowPkmsg)
     ]);
 
-    // ── LID routing fix ───────────────────────────────────────────────────────
-    // Check _pnToLid NOW — after the await above, incoming messages from the
-    // recipient during the usync wait will have populated this map.
-    // For LID-migrated accounts, the message `to` field AND Signal participants
-    // must use the LID JID.  Phone-JID messages are silently accepted by the
-    // server but never delivered to the recipient's LID-registered device.
+    // ── Addressing family ─────────────────────────────────────────────────────
+    // Baileys 7.0.0-rc13 — the release that fixed ack 479 on LID addressing —
+    // derives the whole address family from the JID the caller passed, and
+    // never converts between the two:
     //
-    // WA_DM_ROUTE overrides the choice for diagnosis, because both routes have
-    // been observed failing in different ways and only a live account can tell
-    // them apart:
-    //   pn   — always address the phone JID (how this worked before LID JIDs
-    //          started being decoded at all)
-    //   lid  — always address the LID when one is known (the default below)
-    //   auto — same as lid; the default
-    const routeMode  = (process.env.WA_DM_ROUTE || 'auto').toLowerCase();
-    const lidUser    = this._client._pnToLid && this._client._pnToLid.get(recipientPhone);
-    const useLidRoute = lidUser && routeMode !== 'pn';
-    const routingToJid = useLidRoute ? `${lidUser}@lid` : toJid;
-
-    _whaDbg('[DBG] DM_ROUTE phone=' + recipientPhone +
-      ' routing=' + routingToJid + (useLidRoute ? ' (LID)' : ' (PN)') +
-      ' mode=' + routeMode);
+    //     const targetUserServer = isLid ? 'lid' : 's.whatsapp.net'
+    //     const senderIdentity   = isLid && meLid ? <ourLid> : <ourPn>
+    //     const sessionDevices   = await getUSyncDevices([senderIdentity, jid])
+    //     const finalJid         = jid            // the envelope, unchanged
+    //
+    // Send to a phone JID and everything — envelope, device enumeration,
+    // participant <to> entries — stays on phone JIDs. Send to an @lid and it
+    // all stays LID.
+    //
+    // This used to look the recipient up in _pnToLid and rewrite a
+    // phone-addressed DM into a LID-addressed one, on the reasoning that a
+    // phone-addressed message is accepted but never delivered to a
+    // LID-registered device. That rewrite is what produced the 479s: every
+    // rejected stanza in the traces carried to="...@lid", and both
+    // whatsmeow #859 and the Baileys LID reports describe the ack as appearing
+    // specifically on @lid-addressed sends. Following the caller's JID removes
+    // the mismatch instead of trying to compensate for it.
+    const isLidTarget  = toJid.endsWith('@lid');
+    const routingToJid = toJid;
 
     let otherJids;
-    // Follow the same address family as the routing JID — the participants and
-    // the `to` must agree, so WA_DM_ROUTE=pn has to switch both.
-    if (useLidRoute) {
-      // Fetch bundle + build Signal session for the LID JID.
-      // skipUsync=true: we already know the LID from _pnToLid — skip a second
-      // 15 s usync round-trip and go straight to bundle fetch (device 0 primary).
+    if (isLidTarget) {
+      const lidUser = phoneFromJid(toJid);
       const lidDevices = await this._devMgr.bulkEnsureSessionsForLid(
         lidUser, this._signal, allowPkmsg, /* skipUsync */ true);
-      otherJids = lidDevices.length > 0 ? lidDevices : [routingToJid];
+      otherJids = lidDevices.length > 0 ? lidDevices : [toJid];
     } else {
       otherJids = _recipientDevicesByPhone.length > 0 ? _recipientDevicesByPhone : [toJid];
     }
+
+    _whaDbg('[DBG] DM_ROUTE to=' + toJid + ' family=' + (isLidTarget ? 'LID' : 'PN') +
+      ' devices=[' + otherJids.join(',') + ']');
     // ─────────────────────────────────────────────────────────────────────────
 
     const ownLinkedJids = ownDevices.filter(j => j !== ownMainJid);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "whalibmob",
-  "version": "5.5.77",
+  "version": "5.5.80",
   "description": "WhatsApp library for interaction with WhatsApp Mobile API no web",
   "author": "Kunboruto50",
   "main": "index.js",