whalibmob 5.14.11 → 5.14.13

package/README.md

@@ -430,16 +430,17 @@ The CLI asks what to call it once, on a first run, and remembers the answer in
 
 ### CLI Pairing Code
 
-If the number is already in use on a phone, or the verification SMS never arrives, link to the existing account instead. When it is not obvious which way you mean, `wa connect` asks:
+If the number is already in use on a phone, or the verification SMS never arrives, link to the existing account instead.
+
+`wa connect` works out which of the two a number is set up for by reading its session files, and says which one it chose:
 
 ```
-  how do you want to connect?
-    1) sms           register this number as its own device
-    2) pairing code  link to an existing WhatsApp account (8-digit code)
-  sms or pairing code?  [1/2] 2
+connecting as companion (pairing code)...
 ```
 
-The question is skipped when only one kind of session exists on disk, and when stdin is not a terminal. Force either one:
+A number can hold both — registered over SMS as its own device, and linked as a companion to another account. When it holds both, the one used most recently wins. A half-finished registration does not count as a session either way. When there is nothing to connect with, it says so and names the two commands that would create one, rather than picking a side.
+
+Force either one:
 
 ```sh
 wa connect 919634847671 --sms
@@ -1430,7 +1431,7 @@ the session rather than the environment.
 
 ```sh
 # connect to a number (while already in the shell)
-# asks sms or pairing code when both are possible
+# picks sms or pairing from the session files on disk
 wa> /connect 919634847671
 
 # force one or the other
@@ -1563,7 +1564,7 @@ wa> /quit
 | `/reg code <phone> [method] [--name "Name"]` | Request verification code, optionally naming the account |
 | `/reg confirm <phone> <code> [--name "Name"]` | Complete registration |
 | **Connection** | |
-| `/connect <phone> [sms\|pair]` | Connect to WhatsApp — asks which method when unset |
+| `/connect <phone> [sms\|pair]` | Connect to WhatsApp — picks the method from the session files when unset |
 | `/pair <phone> [code]` | Link to an existing account by 8-digit pairing code |
 | `/disconnect` | Disconnect current session |
 | `/reconnect` | Force reconnection |

package/cli.js

@@ -900,41 +900,60 @@ function openShell(prompt) {
 // Which way in: register this number over SMS as the account's own device, or
 // link to an account that already exists the way WhatsApp Web does.
 //
-// Asked only when it is genuinely ambiguous. If exactly one kind of session is
-// already on disk that one wins, and a non-interactive stdin never blocks on a
-// question nobody is there to answer.
-function hasMobileSession(phone) {
-  return fs.existsSync(storeFileFor(_sessDir, phone));
+// Which kind of session a number has, read off the file rather than guessed.
+//
+// A number can hold both — registered over SMS as its own device, and linked
+// as a companion to some other account — so "the file is there" was never
+// enough to go on. It is also not enough on its own: a registration that was
+// started and never finished leaves a store behind with `registered` still
+// false, and connecting with it can only fail.
+//
+// Returns null when there is nothing usable, otherwise when the session was
+// last written. That timestamp is the tie-breaker below.
+function readSessionKind(file, extra) {
+  if (!fs.existsSync(file)) return null;
+  try {
+    const j = JSON.parse(fs.readFileSync(file, 'utf8'));
+    if (!j.registered) return null;
+    if (extra && !extra(j)) return null;
+    return { mtime: fs.statSync(file).mtimeMs };
+  } catch (_) { return null; }
 }
 
-function hasWebSession(phone) {
-  const f = webStoreFileFor(_sessDir, phone);
-  if (!fs.existsSync(f)) return false;
-  try {
-    const j = JSON.parse(fs.readFileSync(f, 'utf8'));
-    return !!(j.registered && j.me && j.me.id);
-  } catch (_) { return false; }
+function mobileSession(phone) {
+  return readSessionKind(storeFileFor(_sessDir, phone));
 }
 
-function askLoginMethod(phone) {
-  const mob = hasMobileSession(phone);
-  const web = hasWebSession(phone);
-  if (web && !mob) return Promise.resolve('pairing');
-  if (mob && !web) return Promise.resolve('sms');
-  if (!process.stdin.isTTY) return Promise.resolve(mob ? 'sms' : 'pairing');
+function webSession(phone) {
+  return readSessionKind(webStoreFileFor(_sessDir, phone), j => !!(j.me && j.me.id));
+}
 
-  return new Promise(resolve => {
-    const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
-    out('');
-    out('  how do you want to connect?');
-    out('    1) sms           register this number as its own device');
-    out('    2) pairing code  link to an existing WhatsApp account (8-digit code)');
-    rl.question('  sms or pairing code?  [1/2] ', (answer) => {
-      rl.close();
-      const a = String(answer).trim().toLowerCase();
-      resolve((a === '2' || a.startsWith('p')) ? 'pairing' : 'sms');
-    });
-  });
+function hasMobileSession(phone) { return !!mobileSession(phone); }
+function hasWebSession(phone)    { return !!webSession(phone); }
+
+/**
+ * Work out how to connect a number, without asking.
+ *
+ * This used to put a question on the terminal, and the question was worse than
+ * useless: it opened a second reader on the same stdin while the shell's own
+ * was still running, so the two split the answer between them and the one that
+ * mattered usually got nothing. An unrecognised answer then fell through to
+ * "sms" — the more destructive of the two — and a companion session that was
+ * perfectly good was met with a login as a primary device, which the server
+ * answers with a 401 that reads exactly like a revoked session.
+ *
+ * There is nothing to ask. The session files say which kinds exist, and when
+ * both do, the one used most recently is the one being asked for.
+ *
+ * @returns {'sms'|'pairing'|null}  null when the number has no usable session
+ */
+function resolveLoginMethod(phone) {
+  const mob = mobileSession(phone);
+  const web = webSession(phone);
+  if (mob && !web) return 'sms';
+  if (web && !mob) return 'pairing';
+  if (!mob && !web) return null;
+  return web.mtime >= mob.mtime ? 'pairing' : 'sms';
 }
 
 // Handlers for the two things a registration can stop and ask for.
@@ -945,8 +964,18 @@ function askLoginMethod(phone) {
 function registrationPrompts() {
   const prompt = (question) => new Promise((resolve) => {
     if (!process.stdin.isTTY) return resolve(null);
+    // The shell's own reader has to stand down first. Two readline interfaces
+    // on one stdin both take the keypresses, so the answer is split between
+    // them: the shell treats it as a command and this one is left with
+    // nothing. Every other place that asks something mid-session already does
+    // this — the two that did not were where the answer went missing.
+    _rl && _rl.pause();
     const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
-    rl.question(question, (answer) => { rl.close(); resolve(String(answer).trim()); });
+    rl.question(question, (answer) => {
+      rl.close();
+      _rl && (_rl.resume(), _rl.prompt(true));
+      resolve(String(answer).trim());
+    });
   });
 
   return {
@@ -1229,8 +1258,17 @@ async function handleLine(line) {
         const forced = (p[2] || '').toLowerCase();
         const method = forced === 'pair' || forced === 'pairing' ? 'pairing'
                      : forced === 'sms'                          ? 'sms'
-                     : await askLoginMethod(phn);
-        out('connecting...');
+                     : resolveLoginMethod(phn);
+        // Nothing on disk to connect with. Say which of the two things to do
+        // rather than picking one and letting the server explain it as a 401.
+        if (!method) {
+          fail('no session for +' + phn);
+          out('  register it as its own device:  /reg code ' + phn);
+          out('  or link it to an account:       /pair ' + phn);
+          break;
+        }
+        out('connecting as ' + (method === 'pairing' ? 'companion (pairing code)'
+                                                     : 'primary device (sms)') + '...');
         if (method === 'pairing') await doConnectWeb(phn);
         else                      await doConnect(phn);
         break;
@@ -2943,7 +2981,13 @@ async function main() {
     const forced = String(flags.method || '').toLowerCase();
     const method = flags.pair || forced === 'pair' || forced === 'pairing' ? 'pairing'
                  : flags.sms  || forced === 'sms'                          ? 'sms'
-                 : await askLoginMethod(phone);
+                 : resolveLoginMethod(phone);
+    if (!method) {
+      fail('no session for +' + phone);
+      out('  register it as its own device:  wa registration --request-code ' + phone);
+      out('  or link it to an account:       wa pair ' + phone);
+      process.exit(1);
+    }
     // Plain `wa>` until the connection actually opens. Naming the number in the
     // prompt before that says "connected as this number" while the line above
     // it says there is no session, which is the opposite of what happened —

package/lib/Client.js

@@ -6,6 +6,7 @@ const EventEmitter  = require('events');
 const path          = require('path');
 const fs            = require('fs');
 const crypto        = require('crypto');
+const { Mutex }     = require('async-mutex');
 const { NoiseSocket }     = require('./noise');
 const { MessageSender, generateMessageId, makeJid, buildOrGetAdvIdentity } = require('./messages/MessageSender');
 const { checkIfRegistered, checkNumberStatus, requestSmsCode, verifyCode, assertRegistrationKeys, fetchIosVersion, fetchWaVersion } = require('./Registration');
@@ -368,6 +369,33 @@ class WhalibmobClient extends EventEmitter {
     this._numberFixAttempted = false;
     this._pingTimer               = null;
     this._keepTimer               = null;
+    // Both pre-key checks ask the server a question, wait for the answer, and
+    // top the account up if they do not like it. Three things start them —
+    // login, the half-hourly timer, and the server saying it is running low —
+    // and nothing stopped two from being in the air at once. Overlapping runs
+    // each saw the same shortage and each answered it, so the account
+    // generated and uploaded two batches for one gap. Serialised, the second
+    // run asks after the first has finished: the count it gets back is the one
+    // the first run just produced, so it stands down instead of repeating it.
+    // One mutex per client — two accounts in the same process are unrelated
+    // and must not wait on each other.
+    this._preKeyMutex             = new Mutex();
+    // Incoming work runs one item at a time, in arrival order.
+    //
+    // Stanzas arrive faster than they are handled, and the handling is
+    // asynchronous, so without these each one raced the ones before it: two
+    // messages from the same contact could decrypt at once and advance the
+    // same ratchet from the same starting point, and two retry receipts could
+    // tear a session down while the resend for the previous one was still
+    // building it back up.
+    //
+    // Three separate locks, not one. A message whose decryption waits on
+    // something that only arrives as a notification would deadlock against a
+    // shared lock — the notification could never be processed to release it.
+    // Keeping them apart means each queue only ever waits on its own kind.
+    this._messageMutex            = new Mutex();
+    this._receiptMutex            = new Mutex();
+    this._notificationMutex       = new Mutex();
     this._connected     = false;
     this._reconnecting  = false;
     this._reconnectTry  = 0;
@@ -2131,6 +2159,16 @@ class WhalibmobClient extends EventEmitter {
 
   // ─── Message handling ─────────────────────────────────────────────────────
 
+  // Put work on one of the incoming queues.
+  //
+  // Never rejects, and never awaited by the caller: the socket reader must keep
+  // reading, and one stanza that fails must not take the ones queued behind it
+  // with it. What the lock buys is order, not delivery of a result.
+  _queueIncoming(mutex, label, fn) {
+    return mutex.runExclusive(fn).catch(err =>
+      _whaDbg('[DBG] ' + label + '_QUEUE_ERR ' + (err && err.message)));
+  }
+
   async _handleMessage(node) {
     const attrs = node.attrs || {};
     const fromRaw = attrs.from  || null;
@@ -2203,22 +2241,29 @@ class WhalibmobClient extends EventEmitter {
       }
     }
 
+    // The acknowledgement goes out first and stays outside the queue below.
+    // It tells the server the stanza arrived, and it has to be prompt whatever
+    // the decryption goes on to do — holding it behind a queue of other
+    // people's messages is how a client stops looking like it is listening.
     if (skmsgNode && isGroup) {
       this._sendMessageAck(id, fromRaw, partRaw);
       this._sendDeliveryReceipt(id, fromRaw, partRaw);
-      // SKDM must be processed (awaited) before we attempt skmsg decryption,
-      // because the first message from a sender always bundles both together.
-      if (participantsNode) {
-        await this._processSKDMDistribution(from, participant, participantsNode);
-      }
-      this._decryptGroupMessage({ node, from, participant, fromRaw, partRaw, id, ts, skmsgNode });
+      this._queueIncoming(this._messageMutex, 'MSG', async () => {
+        // SKDM must be processed (awaited) before we attempt skmsg decryption,
+        // because the first message from a sender always bundles both together.
+        if (participantsNode) {
+          await this._processSKDMDistribution(from, participant, participantsNode);
+        }
+        await this._decryptGroupMessage({ node, from, participant, fromRaw, partRaw, id, ts, skmsgNode });
+      });
       return;
     }
 
     if (dmEncNode && this._signal) {
       this._sendMessageAck(id, fromRaw, partRaw);
       this._sendDeliveryReceipt(id, fromRaw, partRaw);
-      this._decryptDMMessage({ node, from, participant, fromRaw, partRaw, senderPn, id, ts, dmEncNode });
+      this._queueIncoming(this._messageMutex, 'MSG', () =>
+        this._decryptDMMessage({ node, from, participant, fromRaw, partRaw, senderPn, id, ts, dmEncNode }));
       return;
     }
 
@@ -2335,7 +2380,10 @@ class WhalibmobClient extends EventEmitter {
       (candidates.length > 1 ? ' alts=' + candidates.slice(1).join(',') : '') +
       ' cipherLen=' + cipherBuf.length);
 
-    this._decryptWithCandidates(candidates, encType, cipherBuf, id)
+    // Returned, not discarded: _handleMessage runs this behind the message
+    // queue, and the queue can only hold the next message back for as long as
+    // it can see this one is still running.
+    return this._decryptWithCandidates(candidates, encType, cipherBuf, id)
       .then(async plaintext => {
         this._resolveRetry(id);
         const decoded = this._decodeMsg(plaintext);
@@ -2406,7 +2454,8 @@ class WhalibmobClient extends EventEmitter {
       ? skmsgNode.content
       : Buffer.from(skmsgNode.content || '');
 
-    this._signal.senderKeyDecrypt(from, participant, cipherBuf)
+    // Returned for the same reason as the direct-message path above.
+    return this._signal.senderKeyDecrypt(from, participant, cipherBuf)
       .then(plaintext => {
         this._resolveRetry(id);
         const decoded = this._decodeMsg(plaintext);
@@ -2555,36 +2604,51 @@ class WhalibmobClient extends EventEmitter {
 
     _whaDbg('[DBG] RETRY_RECV msgId=' + msgId + ' from=' + fromStr +
       ' — clearing session + resending\n');
-    this._purgeContactSessions(recipientPhone, 'RETRY');
-
-    // Re-send the message — will create fresh pre-key (pkmsg) sessions.
-    // A group resend must go back through the group path: it needs a fresh
-    // SenderKey distribution, which only _sendGroupMessage builds. Drop the
-    // "already distributed" record first, or the resend would carry the same
-    // bare skmsg the recipient just told us it could not read.
-    // Carry the round count into the resend so its own retry receipts continue
-    // the same chain instead of restarting it at zero.
-    const opts = Object.assign({}, cached.options, { _retryDepth: depth });
-
-    if (cached.isGroup) {
-      const resendId = generateMessageId();
-      if (this._signal && this._signal.senderKeyStore) {
-        this._signal.senderKeyStore.invalidateSKDM(cached.toJid);
+
+    // Everything above this point stays synchronous on purpose. Every device
+    // that could not read the message sends its own receipt, and the cache
+    // entry taken above is what makes only the first of them resend — put an
+    // await in front of it and they all pass the check together.
+    //
+    // From here on it is one at a time. Tearing a contact's sessions down and
+    // building them back up is not something two receipts can be doing at once:
+    // the second purge lands in the middle of the first resend and deletes the
+    // session it had just created, so the resend goes out under a session the
+    // recipient no longer has and draws another retry.
+    return this._queueIncoming(this._receiptMutex, 'RETRY', async () => {
+      this._purgeContactSessions(recipientPhone, 'RETRY');
+
+      // Re-send the message — will create fresh pre-key (pkmsg) sessions.
+      // A group resend must go back through the group path: it needs a fresh
+      // SenderKey distribution, which only _sendGroupMessage builds. Drop the
+      // "already distributed" record first, or the resend would carry the same
+      // bare skmsg the recipient just told us it could not read.
+      // Carry the round count into the resend so its own retry receipts continue
+      // the same chain instead of restarting it at zero.
+      const opts = Object.assign({}, cached.options, { _retryDepth: depth });
+
+      if (cached.isGroup) {
+        const resendId = generateMessageId();
+        if (this._signal && this._signal.senderKeyStore) {
+          this._signal.senderKeyStore.invalidateSKDM(cached.toJid);
+        }
+        _whaDbg('[DBG] RETRY_RESEND group round=' + depth + ' newId=' + resendId + '\n');
+        // Awaited inside the queue, so the next receipt's purge cannot land
+        // while this resend is still choosing and building sessions.
+        await this._sender._sendGroupMessage(
+          cached.toJid, resendId, cached.plaintext, cached.mediaType, opts
+        )
+          .then(r  => _whaDbg('[DBG] RETRY_RESEND group ok id=' + (r && r.id) + '\n'))
+          .catch(e => _whaDbg('[DBG] RETRY_RESEND_ERR: ' + e.message));
+        return;
       }
-      _whaDbg('[DBG] RETRY_RESEND group round=' + depth + ' newId=' + resendId + '\n');
-      this._sender._sendGroupMessage(
-        cached.toJid, resendId, cached.plaintext, cached.mediaType, opts
+
+      await this._sender._sendDMMessage(
+        cached.toJid, cached.msgId, cached.plaintext, cached.mediaType, opts
       )
-        .then(r  => _whaDbg('[DBG] RETRY_RESEND group ok id=' + (r && r.id) + '\n'))
+        .then(r  => _whaDbg('[DBG] RETRY_RESEND ok id=' + r.id + '\n'))
         .catch(e => _whaDbg('[DBG] RETRY_RESEND_ERR: ' + e.message));
-      return;
-    }
-
-    this._sender._sendDMMessage(
-      cached.toJid, cached.msgId, cached.plaintext, cached.mediaType, opts
-    )
-      .then(r  => _whaDbg('[DBG] RETRY_RESEND ok id=' + r.id + '\n'))
-      .catch(e => _whaDbg('[DBG] RETRY_RESEND_ERR: ' + e.message));
+    });
   }
 
   _handleAck(node) {
@@ -3090,9 +3154,13 @@ class WhalibmobClient extends EventEmitter {
         // cleared, so a LID with no known number simply gets looked up the next
         // time something sends to it.
         if (this._signal && fromPhone) {
-          setImmediate(() => {
+          // Queued rather than fired loose. A contact that changes devices
+          // several times in a row — leaving and rejoining a group does it —
+          // sends one of these per change, and two overlapping warm-ups race
+          // each other's session building for the same contact.
+          this._queueIncoming(this._notificationMutex, 'NOTIF', async () => {
             if (!this._connected || !this._devMgr) return;
-            this._devMgr.bulkEnsureSessions([fromPhone], this._signal, false)
+            await this._devMgr.bulkEnsureSessions([fromPhone], this._signal, false)
               .then(() => _whaDbg('[DBG] NOTIF_DEVICES bg-usync done for ' + fromPhone))
               .catch(e  => _whaDbg('[DBG] NOTIF_DEVICES bg-usync err: ' + e.message));
           });
@@ -3490,7 +3558,18 @@ class WhalibmobClient extends EventEmitter {
   // the signed pre-key it is serving — so nothing here depends on guessing how
   // it hashes them. A mismatch means the bundle other people are handed is not
   // the one this session can answer for, and no amount of waiting fixes that.
+  //
+  // Shares _preKeyMutex with _ensureServerPreKeys: both end in the same
+  // replenish-and-upload, so protecting only one of them would leave the same
+  // double upload reachable through the other.
   async _verifyServerKeyBundle(reason) {
+    if (!this._signal) return;
+    return this._preKeyMutex.runExclusive(() => this._verifyServerKeyBundleLocked(reason));
+  }
+
+  async _verifyServerKeyBundleLocked(reason) {
+    // Re-checked inside the lock: the session can be released while a caller
+    // is still waiting its turn.
     if (!this._signal) return;
     try {
       const digest = await this._queryKeyDigest();
@@ -3542,7 +3621,14 @@ class WhalibmobClient extends EventEmitter {
   // Top the server back up when it is running out. Never throws: a session that
   // cannot ask is left exactly as it was rather than losing its connection over
   // a bookkeeping query.
+  //
+  // Runs one at a time — see _preKeyMutex in the constructor.
   async _ensureServerPreKeys(reason) {
+    if (!this._signal) return;
+    return this._preKeyMutex.runExclusive(() => this._ensureServerPreKeysLocked(reason));
+  }
+
+  async _ensureServerPreKeysLocked(reason) {
     if (!this._signal) return;
     try {
       const serverCount = await this._queryServerPreKeyCount();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "whalibmob",
-  "version": "5.14.11",
+  "version": "5.14.13",
   "description": "WhatsApp library for interaction with WhatsApp Mobile API and web ",
   "author": "Kunboruto20",
   "main": "index.js",