fix(reaction): populate _serialized on reaction msg keys - #201847
Open
rmyndharis wants to merge 1 commit into
Open
fix(reaction): populate _serialized on reaction msg keys#201847rmyndharis wants to merge 1 commit into
rmyndharis wants to merge 1 commit into
Conversation
WhatsApp Web's July 2026 build renamed MsgKey's `_serialized` property to the minified `$1`. Reaction assigns both of its keys straight through from data (`msgKey`, `parentMsgKey`), so `reaction.id._serialized` and `reaction.msgId._serialized` come back undefined on that build, even though index.d.ts types both as MessageId, whose `_serialized` is not optional. Reaction is the only Base subclass whose ids are named something other than `data.id`, which is why a sweep for `this.id = data.id` doesn't reach it. Normalize both keys the same way the sibling structures handle theirs. Leaves an already-serialized key untouched, so builds that still send `_serialized` are unaffected.
rmyndharis
added a commit
to rmyndharis/OpenWA
that referenced
this pull request
Jul 16, 2026
…#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.
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #201846.
What
Reactionassigns both of its keys straight through fromdata:On the July 2026 WhatsApp Web build those keys carry
$1instead of_serialized, soreaction.id._serializedandreaction.msgId._serializedareundefined— whileindex.d.tstypes both asMessageId, whose_serializedis not optional. Consumers read it directly and get nothing back, silently.It's the only
Basesubclass whose ids aren't nameddata.id, which is why the sweep in #201832 doesn't reach it. That PR does fixsenderUserJidin the same reaction handler, but these two keys are passed through as objects rather than read, so there was no_serializedaccess there to catch.How
Normalizes both keys, leaving an already-serialized key untouched. Independent of #201832 — it doesn't use
Base._normalizeId, so it applies tomainas-is and the two can land in either order. If #201832 lands first and you'd rather this delegate toBase._normalizeId, happy to rebase it that way.Verified
$1onlymsgId._serialized→'true_1@c.us_M1';remote/fromMe/idpreserved_serializedpresentundefinedNotes
Found while tracking the rename downstream in a project that uses this library. The
message_reactionpath was the one that stayed broken after applying the #201832 changes, which is what led here. Also visible from the outside in the workaround script in #201829, which patchesreaction.msgId._serializedon the consumer side.