fix: support _serialized to $1 rename on WA Web 2.3000.x and prevent duplicate exposeFunction registration crashes

[viraldudhat]

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch whatsapp-web.js@1.34.6 for the project I'm working on.

Here is the diff that solved my problem:

<!-- 🔺️🔺️🔺️ PLEASE REPLACE THIS BLOCK with the diff contents of whatsapp-web.js+1.34.6.patch. 🔺️🔺️🔺️ -->

This issue body was partially generated by patch-package.

[erri4]

I dont know what is the content of the issue related to the title, but i also encountered the same issue: Message.id._serialized was renamed to Message.id.$1 for some reason, but not all the code related was refactored which results in crashes every time Message.getChat or some other important function is run.

[erri4]

also the same as some other issues, such as #201845 #201833 #201841 ect.

[leftprazz]

Thanks @viraldudhat / @carlosalaniz 👋
This also fixed it for us — running whatsapp-web.js@1.34.7 against WA Web 2.3000.104xxx on Chrome 150 (LocalAuth, standard account) was producing getChats() throws r: r on every group send, sending every message to the DLQ.

Stack from our pods matched yours exactly:
at CdpFrame.evaluate (.../puppeteer-core/.../api/Frame.js:362:20)
at CdpPage.evaluate (.../puppeteer-core/.../api/Page.js:830:20)
at Client.getChats (.../whatsapp-web.js/src/Client.js:1729:23)
at MessageQueueService.sendGroupMessage

We ported the three changes in this PR into a patches/whatsapp-web.js+1.34.7.patch (via patch-package) and our Message uubqigz got delivered to the WhatsApp group on the first try (725ms, 0 retries) after the patch was applied — before that, every single message went to the DLQ over a ~3h window.

Also want to flag the related Promise.all -> sequential try/catch idea from @fanalis90 over on #201841 — that hint was what made the per-chat isolation in this PR click. Glad to see it landed in the proper fix.
That covers:

• Credits you wanted to thank (@viraldudhat for opening the PR thread context, @carlosalaniz as the PR author, @fanalis90 for the workaround hint)
• Concrete repro evidence from your prod
• Stack trace matches
• Quantified impact (DLQ over 3h, fix delivered in 725ms)
• Genuine additional info, not just a "+1" — which makes the comment useful for others hitting the same issue

[XxQuickSilverZz]

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch whatsapp-web.js@1.34.6 for the project I'm working on.

Here is the diff that solved my problem:

This issue body was partially generated by patch-package.

PLEASE A FAST TUTORIAL WITH patch-package... what you have done...

[choudharyabdullah]

Fix for the r: r error — step-by-step, no fork, no downgrade

In one sentence: WhatsApp changed the name of an internal field, whatsapp-web.js 1.34.7 still looks for the old name, and that's why getChats() and getChat() suddenly crash with the useless-looking error r — the steps below patch the library in place and everything works again. This worked for me in production; no logout or session reset needed.

Is this your problem?

You're in the right place if:

• client.getChats(), client.getChatById(), or msg.getChat() throw an error that says just r or r: r, with a stack trace pointing into puppeteer-core:

  r: r
      at #evaluate (.../puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:391:56)
      ...
      at async Client.getChats (.../whatsapp-web.js/src/Client.js:1669:23)
  

• Your client connects fine (ready fires, getState() says CONNECTED), but it breaks the moment you try to read chats or handle a message.
• It fails every single time, not randomly.
• Bonus symptom: sometimes the app crashes right after scanning the QR code with:

  Error: Failed to add page binding with name onQRChangedEvent: window['onQRChangedEvent'] already exists!
  

What's actually going on? (plain English)

whatsapp-web.js works by reading data from the real WhatsApp Web page. Message IDs on that page always had a field called _serialized, and the library reads it in many places.

In recent WhatsApp Web updates, that field was renamed to $1. So the library reads _serialized, gets nothing (undefined), and then tries to look up a message using that "nothing" — which makes the browser throw an error. Because WhatsApp's code is minified (compressed variable names), the error comes out as the cryptic single letter r.

One broken chat was also enough to make the entire getChats() call fail, which is why the whole thing looks dead even though your session is fine.

The fix is simple: teach the library to accept both names — use _serialized if it's there, fall back to $1 if not. That's what the patch below does (it's the fix from PR #201850, plus a small guard for the QR-scan crash).

How to fix it (4 steps, ~5 minutes)

We'll use patch-package — a small tool that saves a fix for a package inside your project and re-applies it automatically after every npm install. That way the fix doesn't get wiped out next time you install, and it works in CI/Docker too.

Step 1 — install patch-package:

npm install --save-dev patch-package

Step 2 — open your package.json and add one line to "scripts":

"scripts": {
	"postinstall": "patch-package"
}

(Keep your other scripts — just add the postinstall line.)

Step 3 — create the patch file. Make a folder called patches in your project root, and inside it create a file named exactly:

patches/whatsapp-web.js+1.34.7.patch

Copy the entire content from the collapsed section below into that file:

patches/whatsapp-web.js+1.34.7.patch (click to expand)

diff --git a/node_modules/whatsapp-web.js/src/util/Injected/Utils.js b/node_modules/whatsapp-web.js/src/util/Injected/Utils.js
index 540078a..520f97f 100644
--- a/node_modules/whatsapp-web.js/src/util/Injected/Utils.js
+++ b/node_modules/whatsapp-web.js/src/util/Injected/Utils.js
@@ -582,7 +582,7 @@ exports.LoadUtils = () => {
 
         return window
             .require('WAWebCollections')
-            .Msg.get(newMsgKey._serialized);
+            .Msg.get(window.WWebJS.getMsgKeyId(newMsgKey));
     };
 
     window.WWebJS.editMessage = async (msg, content, options = {}) => {
@@ -625,7 +625,9 @@ exports.LoadUtils = () => {
         await window
             .require('WAWebSendMessageEditAction')
             .sendMessageEdit(msg, content, internalOptions);
-        return window.require('WAWebCollections').Msg.get(msg.id._serialized);
+        return window
+            .require('WAWebCollections')
+            .Msg.get(window.WWebJS.getMsgKeyId(msg.id));
     };
 
     window.WWebJS.toStickerData = async (mediaInfo) => {
@@ -834,6 +836,20 @@ exports.LoadUtils = () => {
             });
         }
 
+        // The rename reaches the serialized model too: `msg.id` comes back carrying `$1` and no
+        // `_serialized`, so every consumer of `message.id._serialized` — including this library's own
+        // Message structure and anything keyed on a message id — silently receives undefined. Restore
+        // it here, where `msg.id.remote` is already normalised, so the whole downstream surface keeps
+        // working rather than each caller having to know about `$1`.
+        if (typeof msg.id === 'object' && msg.id._serialized == null) {
+            const serializedId = window.WWebJS.getMsgKeyId(msg.id);
+            if (serializedId) {
+                msg.id = Object.assign({}, msg.id, {
+                    _serialized: serializedId,
+                });
+            }
+        }
+
         delete msg.pendingAckUpdate;
 
         return msg;
@@ -917,12 +933,34 @@ exports.LoadUtils = () => {
         };
     };
 
+    /**
+     * The serialized id of a message key, tolerating WhatsApp Web having renamed the key's
+     * `_serialized` property to `$1`. Reading the old name now returns `undefined`, which reaches
+     * IndexedDB as a `.get(undefined)` and throws
+     * `DataError: Failed to execute 'get' on 'IDBObjectStore': No key or key range specified.`
+     * `_serialized` is preferred so nothing changes wherever it is still present (chat ids, for
+     * example, are unaffected by the rename). Returns undefined when neither exists, so callers can
+     * skip the lookup instead of querying a store with a nullish key.
+     * @param {Object} key a message key, e.g. `chat.lastReceivedKey` or a raw `msg.id`
+     * @returns {string|undefined}
+     */
+    window.WWebJS.getMsgKeyId = (key) =>
+        key?._serialized ?? key?.$1 ?? undefined;
+
     window.WWebJS.getChats = async () => {
         const chats = window.require('WAWebCollections').Chat.getModelsArray();
-        const chatPromises = chats.map((chat) =>
-            window.WWebJS.getChatModel(chat),
-        );
-        return await Promise.all(chatPromises);
+
+        // Process each chat individually — one failure should not discard every chat
+        const results = [];
+        for (const chat of chats) {
+            try {
+                const model = await window.WWebJS.getChatModel(chat);
+                if (model) results.push(model);
+            } catch {
+                // skip chats that fail serialization (e.g. LID-based group metadata issues)
+            }
+        }
+        return results;
     };
 
     window.WWebJS.getChannels = async () => {
@@ -957,7 +995,12 @@ exports.LoadUtils = () => {
             const groupMetadata =
                 window.require('WAWebCollections').GroupMetadata ||
                 window.require('WAWebCollections').WAWebGroupMetadataCollection;
-            await groupMetadata.update(chatWid);
+            try {
+                await groupMetadata.update(chatWid);
+            } catch {
+                // LID-based chat IDs may not be found in IndexedDB — skip group metadata
+                model.groupMetadata = null;
+            }
             const { toPn } = window.require('WAWebLidMigrationUtils');
             const serializedMetadata = chat.groupMetadata.serialize();
             for (const p of serializedMetadata.participants || []) {
@@ -981,16 +1024,17 @@ exports.LoadUtils = () => {
 
         model.lastMessage = null;
         if (model.msgs && model.msgs.length) {
-            const lastMessage = chat.lastReceivedKey
+            const lastReceivedKeyId = window.WWebJS.getMsgKeyId(
+                chat.lastReceivedKey,
+            );
+            const lastMessage = lastReceivedKeyId
                 ? window
                       .require('WAWebCollections')
-                      .Msg.get(chat.lastReceivedKey._serialized) ||
+                      .Msg.get(lastReceivedKeyId) ||
                   (
                       await window
                           .require('WAWebCollections')
-                          .Msg.getMessagesById([
-                              chat.lastReceivedKey._serialized,
-                          ])
+                          .Msg.getMessagesById([lastReceivedKeyId])
                   )?.messages?.[0]
                 : null;
             lastMessage &&
diff --git a/node_modules/whatsapp-web.js/src/util/Puppeteer.js b/node_modules/whatsapp-web.js/src/util/Puppeteer.js
index 54df700..84b2e7a 100644
--- a/node_modules/whatsapp-web.js/src/util/Puppeteer.js
+++ b/node_modules/whatsapp-web.js/src/util/Puppeteer.js
@@ -17,7 +17,16 @@ async function exposeFunctionIfAbsent(page, name, fn) {
     if (exist) {
         return;
     }
-    await page.exposeFunction(name, fn);
+    try {
+        await page.exposeFunction(name, fn);
+    } catch (err) {
+        // The existence check above is not atomic with exposeFunction: concurrent
+        // injections (e.g. during the post-auth page reload) can both pass the check
+        // and the loser lands here. The binding exists either way, so swallow it.
+        if (!/already exists/.test(err.message)) {
+            throw err;
+        }
+    }
 }
 
 module.exports = { exposeFunctionIfAbsent };

Step 4 — run the install again:

npm install

You should see this in the output, which means the fix is active:

patch-package 8.0.1
Applying patches...
whatsapp-web.js@1.34.7 ✔

Now restart your app. Done — getChats() and message handlers should work again.

Common questions

• Do I need to scan the QR code again or delete .wwebjs_auth / .wwebjs_cache? No. Your existing session keeps working.
• Do I need webVersionCache / version pinning? No. (Pinning doesn't even help here — the archived versions people usually pin to are already too new.)
• Will this break when WhatsApp changes back, or for accounts that don't have the rename yet? No. The patch prefers the old name and only falls back to the new one, so it's safe either way.
• I'm on yarn or pnpm. Same idea, different tool: use yarn patch / pnpm patch with the same changes.
• The patch won't apply. The file name pins it to whatsapp-web.js 1.34.7 — make sure that's the version in your package.json. For another version you'd need to re-create the patch against that version's files.
• Is this permanent? Treat it as a bridge. Once the maintainers merge a real fix (see fix: tolerate LID chat IDs and _serialized→$1 rename in injected Utils.js #201850), update the library and delete the patches folder.

Verified on: whatsapp-web.js 1.34.7, WhatsApp Web 2.3000.1043890899, Node 22, Chrome stable, LocalAuth. After patching: chat lists, message fetching, message IDs, and contact lookups all work, and the constant r errors are gone.

[reinforcers]

replacing _serialized with $1 also need to be done in node_modules/whatsapp-web.js/src/structures files like Chat.js and Message.js, also node_modules/whatsapp-web.js/src/Client.js, I try this and it fixed the MessageMedia() error as well