[Bug]: WhatsApp pushed a WhatsApp Web update that changed how a photo/file is stored internally (the encryption key + path fields). The break: to download a photo, the library reads specific fields, then does .

[uppercrustkrish-sys]

Pre-flight

• I searched existing issues and this isn't a duplicate
• I'm on the latest released version (or noted my version below)

OpenWA version

0.8.17

Deployment

Docker Compose

Database

PostgreSQL

WhatsApp engine

whatsapp-web.js

What happened?

[Bug]: whatsapp photo recognition and forwarding on open wa is not working, WhatsApp pushed a WhatsApp Web update that changed how a photo/file is stored internally (the encryption key + path fields). The break: to download a photo, the library reads specific fields, then does .split() on one of them to get the decryption path. WhatsApp renamed/moved that field → the field is now undefined → .split() of undefined → crash. So: - Photo arrives (bot sees "type: image") ✅ - Downloading the actual bytes crashes ❌. WhatsApp flipped it server-side for all users at once. Every bot on that library version broke simultaneously — not your setup, not your code (git confirmed: no change at that time).

Steps to reproduce

i compress into docker which have openwa image into it which is base of the incomming webhooks then my NLU and NLP understands everything with the help of regx and reply accordingly if the task requires the image of xlsx it transfes ut as well but thats not working now.

Expected behavior

No response

Relevant logs

Environment / additional context

No response

[rmyndharis]

Hi @uppercrustkrish-sys — thanks for the detailed report, and your read is the right one: this isn't anything in your setup or your code. It's a confirmed upstream break in whatsapp-web.js, triggered by a WhatsApp Web build that rolled out around 2026-07-14, and it's hitting everyone on the library at once exactly as you described.

One small correction on the mechanism (it doesn't change the outcome): the field that moved isn't the media encryption key/path, and the failure isn't a .split() on it. Per a well-evidenced upstream report (wwebjs/whatsapp-web.js#201830), the WhatsApp Web JS bundle renamed the serialized message-id property from id._serialized to id.$1 (a minifier-mangled name introduced in the 2.3000.x build range). When whatsapp-web.js downloads media it looks the message up by that serialized id; with the field now undefined the IndexedDB lookup fails (Failed to execute 'get' on 'IDBObjectStore': No key or key range specified), surfacing through Puppeteer as the opaque minified error r: r. So your symptom read (server-side flip → media download fails for all incoming images → every bot broke simultaneously → not user code) is spot on; it's just a different field than the one you suspected.

Where it breaks in OpenWA: we pin whatsapp-web.js@^1.34.7 (resolved 1.34.7 — the latest stable release on npm, from 2026-04-24; no newer stable release exists yet). Our adapter downloads inbound media by delegating to the upstream msg.downloadMedia() call (src/engine/adapters/whatsapp-web-js.adapter.ts:320); the failure happens entirely inside that upstream method, in code OpenWA doesn't own or parse. OpenWA itself never reads or .split()s a WhatsApp encryption-key or media-path field.

On stability: that msg.downloadMedia() call is wrapped in a try/catch (src/engine/adapters/whatsapp-web-js.adapter.ts:548-555, logging Error downloading media), with a second outer guard around the whole inbound handler. So OpenWA isn't crashing — it degrades: the message envelope (type: image, etc.) still reaches your bot/webhook, just without the media bytes. That matches your "photo recognition and forwarding not working" precisely — the bot sees the image but can't get the bytes to forward or OCR. So this is a media-recovery problem, not a process-stability one.

Immediate workaround (temporary, with caveats): the renamed property lives in the WhatsApp Web JS bundle Puppeteer loads, so pinning an older build from before the break may avoid it. Set WWEBJS_WEB_VERSION to a known-good pre-2026-07-14 build in your Docker environment — this bypasses OpenWA's auto-resolve, which right now lands on a 2.3000.x build (the whole range is suspect). Honest caveats: (1) I haven't yet seen anyone confirm a specific older pin works for this particular rename, and WhatsApp can force-retire old builds; (2) old builds expire from the version registry in roughly two months, after which the server refuses them and you hit the QR/auth hang we've seen before (#488/#684) — so if pinning old fixes media now but later your bot can't authenticate, the pin has aged out and you'll need to move forward to a build covered by a fixed library. This is a stopgap, not a fix.

The real fix is an upstream whatsapp-web.js release. PR wwebjs/whatsapp-web.js#201832 adds an id-normalization fallback (copies $1 back into _serialized) but it's open and unmerged as of today. The moment it lands on npm I'll bump OpenWA's ^1.34.7 and cut a patch — until then there's no stable library version I can move to that contains the fix. (A 2.0.0-alpha exists on npm, but it's an alpha and, based on the report, is also affected.)

I did look at whether OpenWA can patch around this locally — e.g. skipping the suspect build range in our web-version resolver, or reconstructing the serialized id before download — but both mean reaching into whatsapp-web.js internals in a way that's fragile and would likely break again on the next upstream change, so I'd rather ship the upstream fix as a clean dependency bump.

To confirm it's the same RCA on your end, could you paste the exact error line from your logs? I'd expect either the opaque r: r or an IndexedDB DataError near the Error downloading media entry. And to rule out a stale image — you're on 0.8.17, which ships whatsapp-web.js@1.34.7, correct?

I'll leave this open to track the upstream fix and bump the dependency as soon as one ships. Thanks for flagging it clearly — the "broke for everyone at once, no local change" framing was exactly right.

[Magnarks]

I applied this fix, wwebjs/whatsapp-web.js#201830 (comment) which resolves many issues with OpenWA, such as the function for retrieving group data. However, I'm still encountering an error where OpenWA doesn't return the message ID, preventing me from using the reply endpoint since I can't pass anything to quotedMessageId.

[rmyndharis]

Correction to my earlier comment — I need to walk back the WWEBJS_WEB_VERSION workaround I suggested above. I'd assumed pinning an older WhatsApp Web build could dodge the rename; that turns out not to work. The author of the upstream fix (lindionez) tested reverting to an older build and reported it "didn't solve the problem" (wwebjs/whatsapp-web.js#201829), and across the upstream threads nobody has confirmed a specific older pin that restores media + message-id. The build registry OpenWA auto-pins from also prunes old builds every few hours, so an older pin isn't reliably servable and WhatsApp retires them quickly anyway. Please don't spend time hunting for a working version pin — it isn't a real escape hatch for this one. Apologies for the misleading suggestion earlier.

@Magnarks — thanks for the detail on the reply endpoint; that's the same root cause as the media break. The id._serialized → id.$1 rename also hits the Message constructor in whatsapp-web.js, so msg.id._serialized comes back undefined — which is exactly why you've got nothing to pass as quotedMessageId, and why ack tracking and quoted-message resolution break alongside it. The community patches in circulation (the sed-style ones, and the media-focused fallbacks) mostly touch Client.js / downloadMedia; they don't reassign this.id in the Message constructor, which is the site OpenWA reads in roughly 40 places to surface a usable id. So on those patches media download may recover while reply/message-id stays broken — matching what you're seeing.

OpenWA's plan: I'll ship a patch release that backports the full upstream fix (whatsapp-web.js#201832 — a _normalizeId helper applied across Message, Chat, Contact, Client, and Utils, restoring _serialized end-to-end). It'll be a build-time backport that auto-disables the moment we bump to a whatsapp-web.js release that includes the fix upstream, so it's a stopgap rather than a fork. I'll follow up here when it's out.

[rmyndharis]

@Magnarks @uppercrustkrish-sys — the backport is ready to try, and I'd rather have your confirmation than my own before I ship it.

PR #758 pulls upstream's fix (wwebjs/whatsapp-web.js#201832 — the _normalizeId one) into the image at build time. Unlike the community patches going around, it covers the Message constructor, which is the site that actually feeds msg.id._serialized — so message ids, media download, acks and reply quoting should all come back together. @Magnarks, that should cover the missing quotedMessageId you hit after applying the community patch.

CI builds a multi-arch image for the PR, so you can test it without waiting for a release:

ghcr.io/rmyndharis/openwa:c7a38b5

Point your compose file at that tag instead of latest, recreate the container, and let a photo come in.

What I'm hoping you can tell me:

• Do inbound photos/files download again (no more Error downloading media in the logs)?
• @Magnarks — does the reply endpoint work, i.e. do you get a real message id to pass as quotedMessageId?
• Anything that looks worse than before.

Being straight with you about why I'm asking rather than just releasing: I've verified the patch applies cleanly on both architectures and the fix itself is well-validated upstream, but nobody has yet run this image against a live session on an affected WhatsApp Web build. That's the one gap I can't close from my side, and I'd rather not move the latest tag for everyone on an inference. A quick "works" or "still broken" from either of you is worth more than another round of testing here.

No rush, and no obligation — if neither of you gets a chance in the next couple of days I'll make a call anyway, since the break is painful enough that waiting indefinitely isn't free either. Thanks for the reports; the detail in both made this a lot easier to chase down.

[rmyndharis]

Update: I ran the fix against a live session on an affected build, so the gap I flagged earlier — nobody having actually tested this end-to-end — is now closed.

Setup: image from #759, linked to a real account, WhatsApp Web pinned to 2.3000.1043250633-alpha (i.e. a build that carries the rename).

Inbound photos download again. Two photos sent from another number came back through downloadMedia() with their bytes intact:

image  fromMe=false  id=false_…_3B6E4C70C5FEE169  →  223,020 bytes  JPEG 1200x1600
image  fromMe=false  id=false_…_3B51D225DB829208  →   74,896 bytes  JPEG 1600x900

Both decode as valid JPEGs, so this isn't "no error logged" — the bytes are really there. Documents came through too (23KB, 24KB).

Message ids resolve. Every id is populated rather than undefined — sending returns a real one (true_148004841455867@lid_3EB0…), and inbound messages carry theirs. Zero occurrences of Error downloading media, the opaque r: r, or the IndexedDB DataError across the whole session.

@Magnarks — the reply endpoint works. I passed a live message id as quotedMessageId and the reply went through (201, with its own id back). getChats also returns chats with valid ids, which was the other half of what you saw.

So the backport covers the full family: media download, message ids, chat resolution, and replies.

One caveat worth stating plainly: reactions are still not attributable on these builds. Reaction is the one structure upstream's fix doesn't reach — I've reported that separately as wwebjs/whatsapp-web.js#201846 with a fix in wwebjs/whatsapp-web.js#201847, and #759 carries a fallback in the meantime so reaction events don't silently attach to the wrong message.

Since this is verified against a live affected build, I'm merging it now rather than holding — the break is painful enough that there's no reason to make anyone wait on further confirmation. It'll be in the next release, and latest will carry it. If anything still looks wrong on your setups afterwards, reopen this or file a fresh issue and I'll pick it straight up.