whalibmob 5.5.78 → 5.5.80

package/lib/messages/MessageSender.js

@@ -693,67 +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.
-    //
-    // 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
+    // ── Addressing family ─────────────────────────────────────────────────────
     // Baileys 7.0.0-rc13 — the release that fixed ack 479 on LID addressing —
-    // keeps the stanza addressed to the JID the caller passed:
-    //     const finalJid = jid;
-    //     const destinationJid = !isStatus ? finalJid : statusJid;
-    // It never rewrites `to` to the LID. The LID is used only to look up
-    // devices, fetch prekeys and address the per-device <to> entries; the
-    // envelope stays on the phone JID. Rewriting the envelope is what draws
-    // 479, which both whatsmeow #859 and the Baileys LID reports describe as
-    // appearing specifically when the message is addressed to an @lid.
+    // derives the whole address family from the JID the caller passed, and
+    // never converts between the two:
+    //
+    //     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
     //
-    // WA_DM_ROUTE=lid restores the old envelope-on-LID behaviour for
-    // comparison; anything else keeps the Baileys shape.
-    const routeMode = (process.env.WA_DM_ROUTE || 'auto').toLowerCase();
-    const lidUser   = this._client._pnToLid && this._client._pnToLid.get(recipientPhone);
-    // Participants still come from the LID device list whenever we know it —
-    // that part matches Baileys too, which encodes @lid per-device JIDs while
-    // leaving the envelope alone.
-    const useLidRoute  = !!lidUser;
-    const routingToJid = (lidUser && routeMode === 'lid') ? `${lidUser}@lid` : toJid;
-
-    _whaDbg('[DBG] DM_ROUTE phone=' + recipientPhone +
-      ' envelope=' + routingToJid + ' participants=' +
-      (useLidRoute ? 'LID' : 'PN') + ' mode=' + routeMode);
+    // 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.78",
+  "version": "5.5.80",
   "description": "WhatsApp library for interaction with WhatsApp Mobile API no web",
   "author": "Kunboruto50",
   "main": "index.js",