fix(client): add fallback for WhatsApp id._serialized renamed to id.$1 by lindionez · Pull Request #201832 · wwebjs/whatsapp-web.js

lindionez · 2026-07-15T00:25:18Z

WhatsApp Web changed the serialized message ID property from _serialized to $1 in its July 2026 update. Any code reading id._serialized received undefined, causing a cascade of TypeError crashes across the entire event pipeline (messages, reactions, polls, media download, quoted messages, etc.).

Changes:

Add Base._normalizeId() static helper that copies $1 into _serialized whenever _serialized is missing, keeping all downstream code compatible
Apply Base._normalizeId() to all structure _patch() methods that assign his.id or his.wid: Message, Chat, Contact, Channel, GroupNotification, Broadcast, ClientInfo
Fix GroupNotification chatId and �uthor object reads to use || \
Fix Message rom, o, �uthor and inviteV4 reads to use || \
Fix Utils.js browser-side: normalize msg.id in getMessageModel, add || \ fallback to ewMsgKey (fixes sendMessage returning empty),
lastReceivedKey, msg.id.remote, chat.id, getMaybeMePnUser(), createWid(p.jid), and userJidToUserWid() calls
Fix Client.js browser-side evaluates: reactions sender, poll vote sender and parentMsgKey, blocked contacts list, lid/phone in getContactLidAndPhone, userJidToUserWid in getCustomerNote, es.gid in �cceptInvite, and participant.wid/createGroupResult.wid in createGroup
Fix GroupChat.js browser-side evaluates: pWid, participant duplicate check, group invite message ID, and lid/phone in emoveParticipants, promoteParticipants, demoteParticipants
Fix Contact.js browser-side: lid in unblock()

Closes #201829
Closes #201830

WhatsApp Web changed the serialized message ID property from _serialized to $1 in its July 2026 update. Any code reading id._serialized received undefined, causing a cascade of TypeError crashes across the entire event pipeline (messages, reactions, polls, media download, quoted messages, etc.). Changes: - Add Base._normalizeId() static helper that copies $1 into _serialized whenever _serialized is missing, keeping all downstream code compatible - Apply Base._normalizeId() to all structure _patch() methods that assign his.id or his.wid: Message, Chat, Contact, Channel, GroupNotification, Broadcast, ClientInfo - Fix GroupNotification chatId and �uthor object reads to use || \ - Fix Message rom, o, �uthor and inviteV4 reads to use || \ - Fix Utils.js browser-side: normalize msg.id in getMessageModel, add || \ fallback to ewMsgKey (fixes sendMessage returning empty), lastReceivedKey, msg.id.remote, chat.id, getMaybeMePnUser(), createWid(p.jid), and userJidToUserWid() calls - Fix Client.js browser-side evaluates: reactions sender, poll vote sender and parentMsgKey, blocked contacts list, lid/phone in getContactLidAndPhone, userJidToUserWid in getCustomerNote, es.gid in �cceptInvite, and participant.wid/createGroupResult.wid in createGroup - Fix GroupChat.js browser-side evaluates: pWid, participant duplicate check, group invite message ID, and lid/phone in emoveParticipants, promoteParticipants, demoteParticipants - Fix Contact.js browser-side: lid in unblock() Closes wwebjs#201829 Co-authored-by: Lindionez <lindionez@users.noreply.github.com> Co-authored-by: Claude <claude@anthropic.com>

N0N4M3BNS · 2026-07-15T05:37:56Z

Working on my side.

@lid

…id._serialized -> id.$1 rename WhatsApp's July 2026 web update renamed message-id's serialized property from _serialized to $1. whatsapp-web.js (still pinned to a pre-fix commit) reads _serialized everywhere, so it silently got undefined - the root cause of sendMessage returning no message object even on a successful send (our earlier @lid workaround was treating a symptom of this, not the actual cause; that workaround stays in place as a harmless safety net). Upstream fix is open as wwebjs/whatsapp-web.js#201832 (closes wwebjs/whatsapp-web.js#201829, #201830) but not yet merged, so pin to the PR author's fork/commit directly until it lands on main. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

WhatsApp Web's July 2026 update renamed the serialized message-ID property from _serialized to $1. Any code reading id._serialized received undefined, causing DataError ('get on IDBObjectStore: No key or key range specified') and cascading failures across media download, getChat, reactions, polls and quoted messages. Ports the fix from upstream wwebjs#201832 (by lindionez): - Base._normalizeId() copies $1 into _serialized when _serialized is missing - applied in _patch() of Message, Chat, Contact, Channel, Broadcast, ClientInfo, GroupNotification - '|| .$1' fallback across Message/GroupChat/GroupNotification and the browser-side evaluates in Client.js and Utils.js (getMessageModel, getChatModel, newMsgKey, editMessage, rejectCall, membership requests) Verified live against WA build 2.3000.1043180520: media download recovered (getMessageModel id normalized -> resolveMediaBlob returns the JPEG blob).

marko-oljaca · 2026-07-15T07:48:38Z

Used this one as well. My bot works again. Thanks for the work!

) merge branch feat/fix-_serialized-id-fallback from lindionez/whatsapp-web.js (upstream PR wwebjs#201832): whatsapp Web (2026-07 update) renamed the _serialized property of id objects to $1; apply the _serialized || $1 fallback across the library and normalize ids at structure boundaries. Conflict resolved in window.WWebJS.sendMessage keeping our sent-message lookup fallbacks, now also $1-aware.

bscdaox · 2026-07-15T14:03:18Z

Have set this up in my environment will report back in 3-6 hours if it bumps into any issues/side affects.

apply upstream PR wwebjs#201832 to prevent ExecutionContext destroyed crashes due to the July 2026 update.

olirock · 2026-07-15T14:33:09Z

Problem solved for me. Thank you!

Sadgman · 2026-07-15T14:53:47Z

Working on my side.

elhumbertoz · 2026-07-15T15:03:16Z

Thank you, problem solved.

ClebersonAlves · 2026-07-15T15:46:53Z

It work for me

fernandomondo · 2026-07-15T16:51:39Z

Tested. It's working on my side. Thanks!

…201832) Adiciona Base._normalizeId (copia $1 -> _serialized) nos _patch das estruturas (Message/Chat/Contact/Channel/GroupNotification/Broadcast/ClientInfo) + fallbacks '_serialized || $1' no Client.js e no codigo injetado (Utils.js), incluindo a normalizacao no getMessageModel. Corrige os erros 'r' (TypeError) em getChats, getContactById, getProfilePicUrl, typing e no processamento de mensagens de entrada. Hunk de Contact.find(lid) do upstream nao se aplica (fork usa outro padrao, ja coberto pela normalizacao de this.id).

AdrielXXO · 2026-07-15T18:58:34Z

@lindionez Thank you so much!

tierracero · 2026-07-15T22:42:25Z

works for me !! Great Job !!!

tierracero · 2026-07-15T22:42:51Z

@lindionez ⚡️ ⚡️ ⚡️ ⚡️ thanks !!!

bscdaox · 2026-07-16T08:25:16Z

Running well since yesterdays comment, nothing bad in the logs!

beri75

Everything looks good from my review. Thanks!

…#747) WhatsApp Web build 2.3000.x (~2026-07-14) renamed the serialized message-id property `id._serialized` to `id.$1`, breaking whatsapp-web.js 1.34.7's downloadMedia(), message-id extraction, ack tracking, and quoted-message resolution for every bot at once. The production image and source installs now backport upstream fix wwebjs/whatsapp-web.js#201832 (Base._normalizeId) into the dependency at build time. The patcher applies the real upstream diff, fails the build loudly on version skew rather than shipping a partial patch, and auto-disables once a whatsapp-web.js release carries the fix upstream. Stopgap, not a fork — it gets removed with the dep bump. Verified against a live session on an affected build (2.3000.1043250633-alpha): inbound photos download with bytes intact (223KB/1200x1600 and 75KB/1600x900 JPEGs), message ids resolve, the reply endpoint accepts a live quotedMessageId, getChats returns valid ids, and no media-download errors fire. Reactions remain unattributable on these builds — Reaction is the one structure upstream's fix doesn't reach. Reported as wwebjs/whatsapp-web.js#201846 with a fix in wwebjs/whatsapp-web.js#201847; an adapter-side fallback here keeps reaction events from attaching to the wrong message meanwhile. Fixes #747.

dolav · 2026-07-16T18:21:06Z

Thanks for working on this! Just wanted to point out that PR #201848 seems to solve this same issue directly at the root in the Puppeteer injection layer (Injected/Utils.js). By intercepting the $1 rename before it reaches the Node models, it prevents the in-page IndexedDB crashes cleanly without needing to patch all the individual Node.js structure files

dpgt · 2026-07-16T20:21:55Z

Thanks for working on this! Just wanted to point out that PR #201848 seems to solve this same issue directly at the root in the Puppeteer injection layer (Injected/Utils.js). By intercepting the $1 rename before it reaches the Node models, it prevents the in-page IndexedDB crashes cleanly without needing to patch all the individual Node.js structure files

This PR fixed it for me.

qwleoz · 2026-07-16T21:50:28Z

While testing this PR on WhatsApp Web 2.3000.1043306118, I encountered a
possible group-message encryption side effect. client.sendMessage() resolves
and returns a valid ID, but the primary phone displays "Waiting for this
message", while another group member can read it.

Full environment and reproduction details: #201849

sirreass · 2026-07-16T22:21:25Z

Thank you for the fix. My bot works again without any changes.

…rialized renamed to id.$1 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Aladdin-ak · 2026-07-18T08:43:00Z

When this fix will be released officically ? Or it will not ?

…eado) O fix do PR wwebjs#201832 normalizou $1->_serialized nos structures via _patch(), mas getNumberId retorna o wid CRU do evaluate — sem normalizacao. Com o bundle novo do WA Web, as chaves do retorno de queryWidExists nao sao mais estaveis: result.wid pode vir sob outra chave e o guard `result.wid === undefined` devolvia null -> numero VALIDO era tratado como not_registered. Sintoma em producao (painel Stefani, desde 16/07): enviar para contato NOVO falha com "Number validation failed: not_registered" mesmo o numero tendo WhatsApp; contatos com chat existente (que nao passam por getNumberId) seguem normais. 11 falhas em 2 dias, zero antes de 16/07. Fix: localizar o wid-like no resultado sob QUALQUER chave (shape {server, user}) e retornar objeto plano explicito {server, user, _serialized} normalizado dentro do browser (onde toString ainda existe — a serializacao do evaluate descarta metodos), com fallback _serialized || $1 || user@server.

Sniperwork · 2026-07-19T13:12:03Z

Works for me brother! Thank you.

galeanil3535 · 2026-07-19T15:25:04Z

Confirmed this patch works end-to-end in production against whatsapp-web.js@1.34.5-alpha.3 (older than main, so line numbers differed — applied manually by matching context rather than via git apply).

Before the patch: sendMessage() for polls returned messageId: undefined, vote_update events carried a parentMsgKey whose _serialized was undefined (only $1 was populated), and our Client.pupPage.evaluate calls that relied on chat.id._serialized (e.g. fetchMessages) threw an opaque single-character error from inside the injected browser code.

One addition beyond the diff here: we also had to patch _serialized normalization directly inside getChatModel / getMessageModel in src/util/Injected/Utils.js (the browser-injected code, not just the Node-side structures). Patching only Base._normalizeId() + the Node-side structures (Message.js, Chat.js, etc.) wasn't sufficient — chat.serialize() inside the page context still returned an id object with only $1 set, so anything downstream that read chat.id._serialized (including Chat.fetchMessages(), which we use to recover a poll's message id when sendMessage itself returns null) kept failing. Once we normalized inside getChatModel/getMessageModel too, sendMessage started returning real message ids again and vote_update → poll-vote matching worked end-to-end (poll sent → customer votes → webhook receives correct pollId → matches our stored record → auto-confirms the underlying business action → notification sent back).

Happy to share the exact Utils.js diff we used against 1.34.5-alpha.3 if useful for anyone stuck on an older version.

pjeuicaro · 2026-07-20T14:31:11Z

Works on my side! Until this repository fix officially the problem, I use your solution, @lindionez .

jalonsoDev · 2026-07-23T18:47:44Z

its working! thanks!

jalonsoDev

🚀

slootjes · 2026-07-24T07:57:44Z

Working here too, thank you!

RCA final: WhatsApp Web renomeou id._serialized -> id.$1 em atualização de julho/2026, quebrando sendMessage() na versão da lib em uso (erro "r: r"). Fix upstream existe (wwebjs/whatsapp-web.js#201832, 4 aprovações, adotado por múltiplos forks independentes) mas ainda não foi mesclado no main oficial. Aplicado como bridge temporário: pin em github:lindionez/whatsapp-web.js #f4ea1e3cf4076e44e36dfe5f81ea57048d2f7761 (commit da própria PR, diff conferido manualmente antes de aplicar). Trocar para o repo oficial assim que a PR mesclar — ver ADR-013 (DOMAIN_INVARIANTS.md) para checklist de retorno e checklist pós-deploy. package-lock.json não pôde ser gerado nesta sessão (sandbox sem acesso à internet) — pendente rodar `npm install` num ambiente com acesso real e commitar o lockfile resultante.

AviFS · 2026-07-24T21:14:40Z

Thank you, this fixed it!! My bot is back online.

github-actions Bot added api changes API modifications utility Utility code labels Jul 15, 2026

Run format

f4ea1e3

github-actions Bot added the typings Type definitions label Jul 15, 2026

Adi1231234 approved these changes Jul 15, 2026

View reviewed changes

claudiocnc mentioned this pull request Jul 15, 2026

[WEBJS] - Unhandled TypeError: Cannot read properties of undefined (reading 'includes') devlikeapro/waha#2158

Closed

Eonus mentioned this pull request Jul 15, 2026

fix: WhatsApp id._serialized -> id.$1 rename + @lid getChatById Eonus21/whatsapp-web.js#143

Merged

fernandomondo mentioned this pull request Jul 15, 2026

fix(message): find sent message indexed under alternate wid (lid/pn) #201839

Open

9 tasks

bscdaox mentioned this pull request Jul 15, 2026

Puppeteer error r: r on getChatById after latest WhatsApp Web update #201838

Open

3 tasks

elhumbertoz added a commit to elhumbertoz/whatsapp-web.js that referenced this pull request Jul 15, 2026

fix: support fallback for message id rename to

9d2cecd

apply upstream PR wwebjs#201832 to prevent ExecutionContext destroyed crashes due to the July 2026 update.

tuyuribr approved these changes Jul 15, 2026

View reviewed changes

2556227850 mentioned this pull request Jul 16, 2026

getChats() throws ExecutionContext error when calling Client.getChats() #201842

Closed

beri75 approved these changes Jul 16, 2026

View reviewed changes

This was referenced Jul 16, 2026

fix(wwjs): backport upstream #201832 to restore id._serialized access (#747) rmyndharis/OpenWA#758

Closed

Reaction msg keys keep _serialized undefined on the $1-rename builds #201846

Open

fix(reaction): populate _serialized on reaction msg keys #201847

Open

rmyndharis mentioned this pull request Jul 16, 2026

sendTextMessage and getChats throw 500 on ready session (whatsapp-web.js) — send succeeds despite the error rmyndharis/OpenWA#757

Closed

2 tasks

qwleoz mentioned this pull request Jul 16, 2026

sendMessage returns a valid message ID but no ACK; message remains "Waiting for this message" and session later logs out #201849

Open

avbasov added a commit to avbasov/whatsapp-web.js that referenced this pull request Jul 17, 2026

Merge PR wwebjs#201832: fix(client): add fallback for WhatsApp id._se…

4a665bd

…rialized renamed to id.$1 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

dallascyclist mentioned this pull request Jul 19, 2026

fix(engine): restore sending on Jul 2026 WhatsApp Web ($1 id rename) — temporary whatsapp-web.js fork pin dallascyclist/OpenWA#1

Open

jalonsoDev approved these changes Jul 23, 2026

View reviewed changes

ShoyebOP mentioned this pull request Jul 25, 2026

sendMessage returns undefined #201857

Open

3 tasks

Uh oh!

Uh oh!

Conversation

lindionez commented Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

N0N4M3BNS commented Jul 15, 2026

Uh oh!

marko-oljaca commented Jul 15, 2026

Uh oh!

bscdaox commented Jul 15, 2026

Uh oh!

olirock commented Jul 15, 2026

Uh oh!

Sadgman commented Jul 15, 2026

Uh oh!

elhumbertoz commented Jul 15, 2026

Uh oh!

ClebersonAlves commented Jul 15, 2026

Uh oh!

fernandomondo commented Jul 15, 2026

Uh oh!

AdrielXXO commented Jul 15, 2026

Uh oh!

tierracero commented Jul 15, 2026

Uh oh!

tierracero commented Jul 15, 2026

Uh oh!

bscdaox commented Jul 16, 2026

Uh oh!

beri75 left a comment

Choose a reason for hiding this comment

Uh oh!

dolav commented Jul 16, 2026

Uh oh!

dpgt commented Jul 16, 2026

Uh oh!

qwleoz commented Jul 16, 2026

Uh oh!

sirreass commented Jul 16, 2026

Uh oh!

Aladdin-ak commented Jul 18, 2026

Uh oh!

Sniperwork commented Jul 19, 2026

Uh oh!

galeanil3535 commented Jul 19, 2026

Uh oh!

pjeuicaro commented Jul 20, 2026

Uh oh!

jalonsoDev commented Jul 23, 2026

Uh oh!

jalonsoDev left a comment

Choose a reason for hiding this comment

Uh oh!

slootjes commented Jul 24, 2026

Uh oh!

AviFS commented Jul 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

lindionez commented Jul 15, 2026 •

edited

Loading