[Bug]: whatsapp-web.js emits no call.received on the 0.23.5+ image while the session stays ready

A whatsapp-web.js session that reliably emitted call.received on the 0.23.4 image stopped emitting anything for real incoming calls after the same session, on the same account and the same profile volume, was moved to an image built from main. The caller's phone rings normally, the session stays ready and keeps receiving messages, but no call event reaches the gateway.

Three things differ between the two images and none of them has been isolated: the bundled browser (Chrome for Testing 146.0.7680.31 against 153.0.8010.36, bumped in 28c41b84), the WhatsApp Web page build the session ran on, and the Debian package set, which the production stage now upgrades at build time (69ea94d5). The engine auth directory was also rekeyed onto the session id in the same window (3d7e3f9a).

Observations

All calls below were placed to the same linked number, from a phone that is not the account itself, and were left ringing for at least ten seconds.

Image	Chrome	WhatsApp Web build	Calls placed	call.received
0.23.4	146.0.7680.31	2.3000.1047471845-alpha	3 on 2026-09-17, 1 on 2026-09-18 09:06 UTC	every time
build of main 62dbe393	153.0.8010.36	2.3000.1047787617-alpha (auto)	2 on 2026-09-18, 09:30 to 09:45 UTC	none
build of main 62dbe393	153.0.8010.36	2.3000.1047471845-alpha (WWEBJS_WEB_VERSION)	1 on 2026-09-18, about 09:51 UTC	none

A detection on the old image looks like this, and no equivalent line appears on the new one:

{"level":"info","context":"SessionEngineLifecycle","message":"Incoming call from 269711229075689:50@lid","callId":"007C3DD07596D295848AA9EB1A2ABE1A","isVideo":false,"isGroup":false,"action":"call_received"}

The session was upgraded in place: the container was recreated on the new image with the same data volume, the auth directory was migrated onto the session id, and the session came back ready without a new scan. During the silent calls the session kept logging inbound messages, so the page itself was alive. The auth directory rename is 3d7e3f9a: the whatsapp-web.js LocalAuth directory is keyed by session id from 0.23.5 on, and a boot migration renames the old name-keyed directory. The profile bytes are the same, the path is not.

What was ruled out

The wiring is the same in both images. client.on('call', call => this.calls.handleIncomingCall(call)) is present in the compiled adapter of both, and the WAWebCallCollection hook is present in node_modules/whatsapp-web.js/src/Client.js in both. That hook is upstream whatsapp-web.js 1.34.7 code, not one of OpenWA's install-time patches: scripts/wwebjs-201832.patch normalizes WhatsApp Web id objects and never touches the call collection. whatsapp-web.js is pinned to 1.34.7 and puppeteer to 24.38.0 in both, and no commit between v0.23.4 and the built image touched the detection path, the patch files, or either pin.

Pinning the WhatsApp Web build that worked on the old image did not bring the event back on the new one, on a single call. That is weaker evidence than it looks: WWEBJS_WEB_VERSION pins the entry HTML fetched from the wppconnect wa-version registry and served into the origin, while the page still loads its scripts from static.whatsapp.net, so the pin does not guarantee the same bundle.

What is not established

Causation. Only one call was placed with the older build pinned, and the reverse experiment was not run: moving the profile back to Chrome 146 wipes its IndexedDB and forces the session to be linked again, so it was not attempted on a session that had to stay usable.

Impact

On 0.23.5 and later images, a whatsapp-web.js session may emit no call.received at all. Call rejection is already Baileys only and answers 501 on this engine, so an auto-reject would fail even with a detected call, and the docs already describe call.received as not reliable on whatsapp-web.js. This is not a documentation gap; it is a behavior change that arrived with the image, on a signal that used to work on the same account.

Suggested investigation

The decisive question is whether the page hook installs at all, and that is answerable on the QR screen without a linked account. Launch each browser with the gateway's real flags, navigate to WhatsApp Web, wait for the QR canvas and evaluate the three conditions the hook needs: that window.require('WAWebCallCollection') resolves, that its on is a function, and that one of its own properties is a Map. whatsapp-web.js skips the whole hook silently when on is not a function, which is exactly the reported symptom: everything else keeps working and no call event can ever fire. Repeating that on each browser with WWEBJS_WEB_VERSION pinned, unset and off is four cells and no account.

Note that whatsapp-web.js pins the user-agent string to Chrome 101 and OpenWA does not override it, so the user agent WhatsApp Web sees is the same on both images. If the page behaves differently it would be through client hints, which still report the real Chromium major, or through feature detection, not the user-agent string. Capturing the static.whatsapp.net bundle URLs on each browser for the same pinned build would settle whether the page build is really held constant.

The failing runs used WhatsApp Web 2.3000.1047787617-alpha. #1643 reports whatsapp-web.js media sends failing on 0.23.5 against the same 2.3000.10477x build family, with the error thrown inside the page bundle, so that build family is already implicated in an unrelated whatsapp-web.js break.

Environment

• OpenWA image built from main at 62dbe393; comparison image ghcr.io/rmyndharis/openwa:0.23.4
• Engine: whatsapp-web.js 1.34.7 on both
• Chrome for Testing 153.0.8010.36 against 146.0.7680.31
• Same account, same session id, same data volume across both images