@oxidezap/baileyrs 0.2.6 → 0.2.8

package/README.md

@@ -295,6 +295,14 @@ What to do instead:
   tens of minutes rather than seconds, and have it alert a human instead of
   killing the process. A shorter one fires on a backoff that was about to
   succeed.
+- Know what your own calls do meanwhile. A call issued while the engine is
+  reconnecting no longer fails fast: it parks and goes out when the connection
+  lands, which on the ladder above can be tens of minutes. That is the point,
+  since the alternative was an error indistinguishable from a finished session,
+  but it means a call you issue during `connecting` is a call you are committing
+  to. Racing it against your own deadline bounds your waiting and not the work:
+  the call still goes out when the reconnect lands, so a retry after the
+  deadline sends it twice unless you pinned `messageId`.
 - Fix the cause on your side: send less. The engine restores the connection,
   but it does not pace your traffic, and the traffic is what earned the `429`.
   Queueing, throttling and deferral are yours to decide, the same as upstream.
@@ -366,6 +374,29 @@ baileyrs auto-wraps, including `useLegacyMultiFileAuthState`. It does not apply
 to `useMultiFileAuthState`, whose `keys` is a projection over the engine's own
 store; the `bridge-` namespaces never surface through it.
 
+The move back down is not symmetric either. From 0.2.8 on, the core buffers a
+skipped-message key as its seed alone, where an earlier release wrote the
+derived cipher/mac/iv triple beside it. Forward is fine — a record written
+before this carries both, and the newer engine reads it unchanged. Backward is
+not: an older engine cannot parse a record whose skipped keys carry no triple,
+and it fails on **the whole record**, not on the one key.
+
+Where that bites depends on which bytes the engine is handed, and a wrapped
+store is not automatically on the safe side of it. It holds the Baileys
+projection, which has only ever held seeds — but it also mirrors the core's
+exact bytes under `bridge-native-session`, and a read prefers that mirror for as
+long as its fingerprint still matches the projection. A downgrade can therefore
+be handed the newer record with a perfectly readable projection sitting right
+beside it.
+
+Dropping a mirror row makes the next read rebuild it from the projection, which
+is the format both versions agree on — but only for a session that has one. A
+session that turned native-only lives in that row alone, so dropping *that* one
+loses the session outright, which is the case the warning above is about. A
+session with no skipped keys buffered at the time is unaffected either way: the
+difference only exists while a chain is holding keys for messages that arrived
+out of order.
+
 ## Disclaimer
 
 This project is not affiliated with, endorsed by, or in any way officially connected to

package/lib/Socket/events.js

@@ -35,7 +35,17 @@ const emitCBEvents = (ctx, node) => {
     const id = l1.id;
     if (id)
         ws.emit(`${DEF_TAG_PREFIX}${id}`, node);
-    for (const [key, val] of Object.entries(l1)) {
+    // `for..in` over the attrs rather than `Object.entries`: this runs for every
+    // stanza the socket sees and the pair array it built was thrown away
+    // immediately. `Object.entries` was own-only by construction though, and
+    // `BinaryNode` is public, so the walk is guarded rather than trusting every
+    // caller to hand over an attrs map with a bare prototype. An inherited
+    // enumerable would otherwise fire CB events for an attr the stanza does not
+    // carry; the check costs nothing next to the emits below.
+    for (const key in l1) {
+        if (!Object.hasOwn(l1, key))
+            continue;
+        const val = l1[key];
         if (l2)
             ws.emit(`${DEF_CALLBACK_PREFIX}${l0},${key}:${val},${l2}`, node);
         ws.emit(`${DEF_CALLBACK_PREFIX}${l0},${key}:${val}`, node);

package/lib/Utils/messages.js

@@ -612,13 +612,54 @@ export const generateWAMessage = async (jid, content, options) => {
         : options;
     return generateWAMessageFromContent(jid, await generateWAMessageContent(content, contentOptions), options);
 };
+/**
+ * The content keys that carry almost every message on a live socket, settled by
+ * identity before the structural predicate runs. Every name here already
+ * satisfies that predicate, so this only shortcuts the substring scan; it never
+ * changes which key wins.
+ */
+const isCommonContentKey = (key) => {
+    switch (key) {
+        case 'conversation':
+        case 'extendedTextMessage':
+        case 'imageMessage':
+        case 'videoMessage':
+        case 'audioMessage':
+        case 'stickerMessage':
+        case 'documentMessage':
+        case 'reactionMessage':
+        case 'protocolMessage':
+        case 'pollCreationMessage':
+            return true;
+        default:
+            return false;
+    }
+};
 /** Get the key to access the true type of content */
 export const getContentType = (content) => {
-    if (content) {
-        const keys = Object.keys(content);
-        const key = keys.find(k => (k === 'conversation' || k.includes('Message')) && k !== 'senderKeyDistributionMessage');
-        return key;
+    if (!content) {
+        return undefined;
     }
+    // The answer stays positional (the first own key naming content wins), but
+    // the scan is an indexed loop with an early return instead of `Array.find`,
+    // so no closure is allocated and the common keys never reach `includes`.
+    //
+    // Deliberately still `Object.keys` and not `for..in`: a decoded
+    // `WAProto.Message` inherits a default for every field of the schema, so
+    // `for..in` would enumerate ~100 prototype keys per call (and would have to
+    // filter them back out with `hasOwn` to stay positional) where `Object.keys`
+    // yields only the handful that were actually set.
+    const keys = Object.keys(content);
+    for (let i = 0; i < keys.length; i++) {
+        const key = keys[i];
+        if (isCommonContentKey(key)) {
+            return key;
+        }
+        if (key.includes('Message') && key !== 'senderKeyDistributionMessage') {
+            return key;
+        }
+    }
+    return undefined;
 };
 const getFutureProofMessage = (message) => message?.ephemeralMessage ||
     message?.viewOnceMessage ||

package/lib/WABinary/jid-utils.js

@@ -57,8 +57,52 @@ export const jidDecode = (jid) => {
         device: device ? +device : undefined
     };
 };
+const CHAR_DEVICE_SEP = 58; // ':'
+const CHAR_AGENT_SEP = 95; // '_'
+/**
+ * Index at which the user component ends, given the index of the '@'.
+ *
+ * `jidDecode` derives the user by splitting the pre-`@` half on ':' and then on
+ * '_', so the user always runs to whichever of ':' or '_' comes first, and to
+ * the '@' when neither is there. Locating that boundary answers both callers
+ * below without the intermediate arrays and result object `jidDecode` allocates.
+ */
+const userEndBefore = (jid, sepIdx) => {
+    for (let i = 0; i < sepIdx; i++) {
+        const code = jid.charCodeAt(i);
+        if (code === CHAR_DEVICE_SEP || code === CHAR_AGENT_SEP) {
+            return i;
+        }
+    }
+    return sepIdx;
+};
+/** As above, or -1 when the JID has no server part: the case `jidDecode` reports as `undefined`. */
+const userEnd = (jid) => {
+    const sepIdx = jid.indexOf('@');
+    return sepIdx < 0 ? -1 : userEndBefore(jid, sepIdx);
+};
 /** Compare the user component of two JIDs, matching upstream Baileys. */
-export const areJidsSameUser = (jid1, jid2) => jidDecode(jid1)?.user === jidDecode(jid2)?.user;
+export const areJidsSameUser = (jid1, jid2) => {
+    // Same answer as comparing `jidDecode(...)?.user`, compared in place: this
+    // runs once per participant check on the message pipeline, and decoding both
+    // sides allocated four arrays and two objects only to throw them away.
+    const end = typeof jid1 === 'string' ? userEnd(jid1) : -1;
+    if (end !== (typeof jid2 === 'string' ? userEnd(jid2) : -1)) {
+        return false;
+    }
+    // Neither side decodes, so upstream compares `undefined === undefined`.
+    if (end < 0) {
+        return true;
+    }
+    const left = jid1;
+    const right = jid2;
+    for (let i = 0; i < end; i++) {
+        if (left.charCodeAt(i) !== right.charCodeAt(i)) {
+            return false;
+        }
+    }
+    return true;
+};
 export const isJidMetaAI = (jid) => jid?.endsWith('@bot');
 export const isPnUser = (jid) => jid?.endsWith('@s.whatsapp.net');
 export const isLidUser = (jid) => jid?.endsWith('@lid');
@@ -71,12 +115,25 @@ export const isHostedPnUser = (jid) => jid?.endsWith('@hosted');
 const botRegexp = /^1313555\d{4}$|^131655500\d{2}$/;
 export const isJidBot = (jid) => jid && botRegexp.test(jid.split('@')[0]) && jid.endsWith('@c.us');
 export const jidNormalizedUser = (jid) => {
-    const result = jidDecode(jid);
-    if (!result) {
+    if (typeof jid !== 'string') {
+        return '';
+    }
+    const sepIdx = jid.indexOf('@');
+    if (sepIdx < 0) {
         return '';
     }
-    const { user, server } = result;
-    return jidEncode(user, server === 'c.us' ? 's.whatsapp.net' : server);
+    // Everything between the user and the '@' is exactly what normalization
+    // drops, so the boundary is all this needs. `jidDecode` would split the same
+    // half twice and box the pieces in an object only for them to be re-joined.
+    const end = userEndBefore(jid, sepIdx);
+    // Fast path for the shape that dominates the pipeline: nothing to strip and a
+    // server `jidEncode` re-emits verbatim, so the JID already is its own normal
+    // form and no new string has to be built at all.
+    if (end === sepIdx && !jid.endsWith('@c.us')) {
+        return jid;
+    }
+    const server = jid.slice(sepIdx + 1);
+    return jidEncode(jid.slice(0, end), server === 'c.us' ? 's.whatsapp.net' : server);
 };
 export const transferDevice = (fromJid, toJid) => {
     const deviceId = jidDecode(fromJid)?.device || 0;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@oxidezap/baileyrs",
   "type": "module",
-  "version": "0.2.6",
+  "version": "0.2.8",
   "description": "A Rust-powered WhatsApp Web library for JavaScript, with a Baileys-compatible API",
   "keywords": [
     "whatsapp",
@@ -82,7 +82,7 @@
   },
   "dependencies": {
     "@hapi/boom": "^9.1.4",
-    "@oxidezap/whatsapp-rust-bridge": "0.16.0",
+    "@oxidezap/whatsapp-rust-bridge": "0.18.0",
     "long": "^5.3.2",
     "pino": "^10.3.1",
     "protobufjs": "^7.6.5"