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

[Hossamudin]

Pre-flight

• I searched existing issues and this isn't a duplicate (closest is Session crashes with "Execution context was destroyed" after upgrading — stale Chromium browser cache #708, which is the stale-Chromium-profile issue — different root cause, see below)
• I'm on the latest released version

OpenWA version

v0.8.17 (also reproduced on the version before this, prior to upgrading via docker compose pull && docker compose up -d)

Deployment

Docker Compose (standalone), Postgres database, ENGINE_TYPE=whatsapp-web.js (whatsapp-web.js v1.34.7, unchanged across the 0.8.17 bump)

WhatsApp engine

whatsapp-web.js

What happened?

Two related endpoints throw 500s on an authenticated, ready session, even on a completely fresh session (deleted data/sessions/session-<name> and re-scanned the QR code — this is not the stale-Chromium-profile issue from #708, which I hit and fixed separately during the same upgrade).

1. GET /api/sessions/:id/chats always 500s:

ERROR [ExceptionsHandler] r: r
    at #evaluate (puppeteer-core/lib/cjs/puppeteer/cdp/ExecutionContext.js:391:56)
    at async ExecutionContext.evaluate (.../ExecutionContext.js:277:16)
    at async IsolatedWorld.evaluate (.../IsolatedWorld.js:100:16)
    at async CdpFrame.evaluate (.../Frame.js:362:20)
    at async CdpPage.evaluate (.../Page.js:830:20)
    at async Client.getChats (whatsapp-web.js/src/Client.js:1669:23)
    at async WhatsAppWebJsAdapter.getChats (dist/engine/adapters/whatsapp-web-js.adapter.js:1372:23)
    at async SessionService.getChats (dist/modules/session/session.service.js:1012:28)

The dashboard's Chats page is unusable as a result (same 500).

2. POST /api/sessions/:id/messages/send-text 500s — but the message is actually delivered:

ERROR [ExceptionsHandler] TypeError: Cannot read properties of undefined (reading 'id')
    at WhatsAppWebJsAdapter.sendTextMessage (dist/engine/adapters/whatsapp-web-js.adapter.js:680:21)
    at async MessageService.sendText (dist/modules/message/message.service.js:62:19)

Looking at the adapter source:

async sendTextMessage(chatId, text, mentions) {
    this.ensureReady();
    const msg = await this.sendResolved(chatId, to => mentions?.length ? this.client.sendMessage(to, text, { mentions }) : this.client.sendMessage(to, text));
    return {
        id: msg.id._serialized,   // <-- throws when msg is undefined
        timestamp: msg.timestamp,
    };
}

this.client.sendMessage(...) (whatsapp-web.js) is resolving with undefined (or something missing .id) instead of a Message instance — but the underlying WhatsApp send already completes. I confirmed this by directly checking the recipient's phone across multiple sends in this session: every one that I was able to confirm the recipient's side of arrived on WhatsApp, even though the API returned {"statusCode":500,"message":"Internal server error"} for every one.

This makes the send-text success/failure response completely unreliable — callers building any kind of send-tracking on top of this API cannot tell a real failure (message never sent) from this false negative (message sent, wrapper crashed after the fact). For anything that logs delivery state to avoid duplicate sends, that ambiguity is the actually dangerous part.

Steps to reproduce

1. Have a ready session on whatsapp-web.js engine.
2. GET /api/sessions/:id/chats → 500, Client.getChats trace as above.
3. POST /api/sessions/:id/messages/send-text with any valid chatId → 500, TypeError trace as above, but message arrives on the recipient's device.
4. Deleting the session profile dir and re-scanning the QR code (full fresh session) does not change the behavior.

Root cause hypothesis

Something in WhatsApp Web's current internal Store surface has drifted from what whatsapp-web.js@1.34.7 expects — both crashes bottom out in Page.evaluate() calls into injected Store-dependent code (Client.getChats, and whatever Client.sendMessage reads internally to build its return value). This looks like the same class of problem as the pinned WhatsApp Web version (2.3000.1043220887-alpha, logged as Pinning WhatsApp Web version ... on session init) no longer matching what whatsapp-web.js@1.34.7's injected scripts assume, similar in spirit to the media-storage change referenced in #747.

Suggested fixes

• Bump the bundled whatsapp-web.js past 1.34.7 if a newer release addresses the Store surface change (this OpenWA release didn't change that dependency version, package.json still shows 1.34.7).
• Regardless of the underlying fix, sendTextMessage should not let a malformed/undefined return value from client.sendMessage() produce a 500 when the send call itself resolved without throwing — right now a resolved-but-shape-mismatched response is indistinguishable from a genuine failure, which is worse than just returning a best-effort result (e.g. omit id/timestamp rather than throwing) since it makes the API actively lie about delivery.

[helal86]

+1 getting this error too on the latest version of OpenWA

[fhirzall]

+1 getting the same error

[rmyndharis]

Thanks for the trace, and for checking delivery on the recipient devices — that second detail is what makes this diagnosable rather than a guess. Both crashes are confirmed, they share one root cause, and it is the same one as #747. Your read that the Store surface moved under whatsapp-web.js 1.34.7 is right. One part of the follow-up isn't, and I want to correct that plainly before anyone spends time on it.

What actually changed

WhatsApp Web minified the serialized property on WAWebMsgKey from _serialized to $1. This is observable in the bundles, not inferred. Comparing your pinned build against the last build before it:

2.3000.1043085068-alpha (07-13):        __d("WAWebMsgKey", … this._serialized=E.join("_")} … toString=function(){return this._serialized}
2.3000.1043220887-alpha (07-15, yours): __d("WAWebMsgKey", … this.$1=E.join("_")}          … toString=function(){return this.$1}

Within that module _serialized goes 2 → 0 and $1 goes 0 → 2.

Important scoping detail: the rename is limited to MsgKey. WAWebWid still sets this._serialized in your build, so chat and contact ids are fine — only message keys broke. Both of your crashes are MsgKey reads.

Crash 2 — send-text 500s while the message arrives

This one is traceable end-to-end in the installed source, and your device observation is exactly what the code predicts. In the injected helper, whatsapp-web.js builds the key itself:

// Utils.js:445
const newMsgKey = new (window.require('WAWebMsgKey'))({ from, to: chat.id, id: newId, participant, selfDir: 'out' });

then dispatches, and only afterwards reads the message back out of the collection by that key:

// Utils.js:576-579
const [msgPromise, sendMsgResultPromise] = window.require('WAWebSendMsgChatAction').addAndSendMsgToChat(chat, message);
await msgPromise;
// Utils.js:585
return window.require('WAWebCollections').Msg.get(newMsgKey._serialized);

On your build that argument is undefined, Msg.get(undefined) misses, and the miss is swallowed through two ternaries that never throw — Client.js:1550 return msg ? window.WWebJS.getMessageModel(msg) : undefined; then Client.js:1558 return sentMsg ? new Message(this, sentMsg) : undefined;. So client.sendMessage() resolves undefined for a message that is already on the wire, and the adapter then dereferences msg.id on it.

Your error text confirms the shape: reading 'id' means msg itself is undefined. A defined message with a renamed id would have said reading '_serialized'.

The read at 585 is strictly after the dispatch at 578, so the 500 cannot prevent the send — that's structural, not a race, which matches what you saw on the recipient devices. One precision worth stating: await msgPromise is the add/dispatch, not the server ack (sendMsgResultPromise is only awaited under waitUntilMsgSent, which we never set). So the source guarantees dispatch-before-the-failing-read; your device checks are what establish delivery. Nobody should read a 500 here as proof of delivery.

Crash 1 — GET /chats always 500s with r: r

Same rename, different site. window.WWebJS.getChatModel reads chat.lastReceivedKey._serialized (Utils.js:987 and :992) — also a MsgKey, also undefined now. Msg.get(undefined) returns undefined without throwing, so the || falls through to Msg.getMessagesById([undefined]), which throws from WhatsApp Web's IndexedDB layer. Upstream unminified that exact signature on a sibling build: DataError: Failed to execute 'get' on 'IDBObjectStore': No key or key range specified (wwebjs#201830). puppeteer renders a custom minified error class with an empty message as literally r: r — a real TypeError would have carried its full text through, which is why crash 2 is readable and crash 1 is not.

getChats fans every chat out through Promise.all (Utils.js:920-926), so one bad chat rejects the whole evaluate. That's why it's 100% rather than partial, and why our own per-chat chat.id?._serialized skip guard never runs — the rejection crosses the CDP boundary before any Node-side loop starts. Your stack matches the installed file exactly: Client.js:1669:23 is the await this.pupPage.evaluate in getChats, with column 23 landing on the await.

On bumping whatsapp-web.js — this is the part that doesn't work

There's nothing to bump to. npm view whatsapp-web.js dist-tags → { next: '1.34.5-alpha.3', latest: '1.34.7' }, and 1.34.7 was published 2026-04-24 — eleven weeks before the rename, so no published release can contain a fix for it. (The only semver-higher string on the registry, 2.0.0-alpha.0, is a deprecated 2023 alpha and outside ^1.34.7.) The upstream fix, PR #201832, is still OPEN with mergedAt: null, and upstream main has no _normalizeId either — so even a git-ref install of upstream main wouldn't help. Our ^1.34.7 pin already resolves to the newest release that exists.

That leaves a build-time patch of node_modules as the only route today. #758 backports #201832 (12 files, 39 hunks, minus one hunk targeting a LID code path that doesn't exist in 1.34.7); #759 stacks on it so source installs get the same treatment as the Docker image. Verified against the real installed 1.34.7 — it applies, and the two hunks that matter for you land:

// Utils.js:585
.Msg.get(newMsgKey._serialized || newMsgKey.$1);
// Utils.js:992
const _lastReceivedKeyId = chat.lastReceivedKey ? chat.lastReceivedKey._serialized || chat.lastReceivedKey.$1 : null;

The second also re-gates lastMessage on that derived id instead of on chat.lastReceivedKey truthiness, so if WhatsApp re-mangles the name again, /chats degrades to a missing last-message preview instead of throwing. $1 is a minifier-generated name and will churn eventually, so that structural gate matters more than the name match.

On your second point — you're right, and it's separate work

A send that resolved must not surface as a 500 indistinguishable from a real failure. The backport doesn't fix that; it removes today's trigger. whatsapp-web.js's own typings hide the problem (sendMessage(...): Promise<Message> at index.d.ts:207-211, while Client.js:1558 returns undefined), which is why the same unguarded msg.id._serialized exists at seven send sites in the adapter, not one.

The reason it isn't a one-liner: Client.js:1558 collapses two opposite meanings into the same undefined — "chat could not be resolved, nothing was sent" (Client.js:1539 if (!chat) return null) and "sent, id unreadable" (your case). Blanket-mapping undefined to success-with-no-id today would trade your false negative (visible, retryable) for a false positive on the first path — a 201 for a message that never left, which is silent loss and strictly worse. So the order is: land the patch so ids are real again, then land the guard as a permanent floor, returning an empty id that persists as NULL rather than a synthesised one. That's the open discussion on #752.

Ship path

Not in any tag yet — v0.8.17 can't have it, and there's no image to pull that does. #758 and #759 are open; next cut is v0.8.18. When it lands:

• Compose file from this repo (it builds from source, no image ref): git pull && docker compose build && docker compose up -d. Note docker compose pull is a no-op for you.
• GHCR image: docker compose pull && docker compose up -d once v0.8.18 is tagged.

There's no useful in-container workaround meanwhile: the v0.8.17 image ships no patch binary, and node_modules is read-only at runtime.

Two asks, if you have the bandwidth:

1. Once v0.8.18 is out, confirm send-text returns a real id rather than a 201 with an empty one — that's the difference between the patch working and it merely not throwing.
2. If you're willing to run a patched build before the tag, /api/sessions/:id/chats returning a populated list (not an empty one) is the signal I most want, since the chat-list path has the least direct evidence behind it.

Tracking #757 against #747 for the root cause and #752 for the contract half. Not closing it as a duplicate — the send-must-not-500 half is its own fix.

[rmyndharis]

v0.8.18 is out, and it fixes both crashes reported here.

The root cause was confirmed exactly as diagnosed: WhatsApp Web renamed the serialized property on WAWebMsgKey from _serialized to $1, and both failures were MsgKey reads inside the injected page code — the chat-list read (chat.lastReceivedKey) and the send read-back (Msg.get(newMsgKey._serialized)). The fix backports upstream #201832 into the installed dependency at build time, and it self-disables the moment a whatsapp-web.js release ships the fix upstream.

It was verified against a live session on a build that actually carries the rename (2.3000.1043250633-alpha) rather than only in review:

• Inbound photos download with their bytes intact — 223KB JPEG 1200x1600 and 75KB 1600x900, both decoding as valid images
• Sending returns a real message id again (true_…@lid_3EB0…)
• getChats returns chats with valid ids — the endpoint that was 500ing for you
• reply works with a live quotedMessageId
• Zero occurrences of the opaque r: r, the IndexedDB DataError, or Error downloading media across the session

Upgrading

• Using the compose file from this repo (it builds from source, no image reference): git pull && docker compose build && docker compose up -d. Note that docker compose pull is a no-op for you.
• Using the GHCR image: docker compose pull && docker compose up -d.

On your second point

You were right, and it was a separate fix. The backport removes today's trigger, but it doesn't address the contract: client.sendMessage() can resolve with undefined instead of throwing, and the same unguarded id read existed at seven send sites — the typings hide it, declaring Promise<Message>.

#762 fixes that and lands in the next release. One correction worth stating, since it shaped the fix: the intuition that a resolved send means the message went out doesn't hold. Client.js:1558 collapses two opposite outcomes into that single undefined — the chat couldn't be resolved and nothing was sent (Client.js:1539), or the message was dispatched and only its id was unreadable. Returning a best-effort result for both would have traded your false negative, which is visible and retryable, for a silent false positive: a 201 for a message that never left. So an absent message is now reported as a failed send, while a message whose id merely can't be read reports an empty id — never a synthesised one.

Closing this as fixed. @helal86, @fhirzall — v0.8.18 covers what you were seeing too. If anything still looks wrong after upgrading, reopen this or file a fresh issue and I'll pick it up.

One known gap, tracked separately: reactions are still not attributable on these builds — Reaction is the one structure upstream's normalization doesn't reach. That's reported upstream as #201846 with a fix in #201847, and v0.8.18 carries a fallback so reaction events don't silently attach to the wrong message in the meantime.

Thanks for the trace and for checking delivery on the recipient devices — that detail is what made this diagnosable rather than guesswork.