fix: ready event not fire on some accounts | guard missing WAWebSetPushnameConnAction during Store injection #5738
+444
−270
Conversation
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
…shnameConnAction during Store injection
This was referenced Jan 20, 2026
|
are u able to share some code example so ppls can benefit from the solution and thanks for your work much appriciated. |
|
As a temporary solution in my project, I implemented a timeout-based safeguard for the ready event. If the ready event is not emitted within a predefined time window after initialization, the client is reinitialized. This process is repeated until the ready event is successfully triggered. |
after that sending messages etc work without any error? |
|
I am using this fork and it seems to work though im not sure if its because of the fork or because i re-initialized with the QR again |
Yes. if Ready event is emitted, sending messages correctly |
|
This fork still doesnt work for me. |
|
Doesnt work for me to. |
timothydillan
added a commit
to timothydillan/whatsapp-web.js
that referenced
this pull request
Jan 28, 2026
This commit addresses multiple root causes that can prevent the ready event from firing after several days of operation: 1. Race condition fix: Check if hasSynced is already true before registering the change listener, as fast session restores may complete before the listener is attached (PR pedroslopez#5748) 2. Page navigation detection: Track listener registration state in both client-side (_authEventListenersInjected) and page context (window._authListenersRegistered) to re-register after navigation 3. Error handling: Wrap onAppStateHasSyncedEvent in try-catch to emit AUTHENTICATION_FAILURE instead of silently failing 4. Duplicate event prevention: Add _readyEmitted flag to prevent multiple READY events if hasSynced toggles 5. Store property guards: Add null checks for all Store properties (Msg, AppState, Conn, Call, Chat, etc.) in attachEventListeners to handle WhatsApp A/B testing variations where some modules may not be available 6. IndexedDB persistence: Request storage persistence and add delay in destroy() to allow pending writes to flush, preventing session corruption especially for Business WhatsApp accounts Fixes: pedroslopez#5717, pedroslopez#5685, pedroslopez#3971 See also: PR pedroslopez#5748, PR pedroslopez#3972, PR pedroslopez#5738
barnwell
pushed a commit
to barnwell/whatsapp-web.js
that referenced
this pull request
Jan 28, 2026
This commit addresses multiple root causes that can prevent the ready event from firing after several days of operation: 1. Race condition fix: Check if hasSynced is already true before registering the change listener, as fast session restores may complete before the listener is attached (PR pedroslopez#5748) 2. Page navigation detection: Track listener registration state in both client-side (_authEventListenersInjected) and page context (window._authListenersRegistered) to re-register after navigation 3. Error handling: Wrap onAppStateHasSyncedEvent in try-catch to emit AUTHENTICATION_FAILURE instead of silently failing 4. Duplicate event prevention: Add _readyEmitted flag to prevent multiple READY events if hasSynced toggles 5. Store property guards: Add null checks for all Store properties (Msg, AppState, Conn, Call, Chat, etc.) in attachEventListeners to handle WhatsApp A/B testing variations where some modules may not be available 6. IndexedDB persistence: Request storage persistence and add delay in destroy() to allow pending writes to flush, preventing session corruption especially for Business WhatsApp accounts Fixes: pedroslopez#5717, pedroslopez#5685, pedroslopez#3971 See also: PR pedroslopez#5748, PR pedroslopez#3972, PR pedroslopez#5738
raffareis
pushed a commit
to xmacna/whatsapp-web.js
that referenced
this pull request
Jan 29, 2026
This commit addresses multiple root causes that can prevent the ready event from firing after several days of operation: 1. Race condition fix: Check if hasSynced is already true before registering the change listener, as fast session restores may complete before the listener is attached (PR pedroslopez#5748) 2. Page navigation detection: Track listener registration state in both client-side (_authEventListenersInjected) and page context (window._authListenersRegistered) to re-register after navigation 3. Error handling: Wrap onAppStateHasSyncedEvent in try-catch to emit AUTHENTICATION_FAILURE instead of silently failing 4. Duplicate event prevention: Add _readyEmitted flag to prevent multiple READY events if hasSynced toggles 5. Store property guards: Add null checks for all Store properties (Msg, AppState, Conn, Call, Chat, etc.) in attachEventListeners to handle WhatsApp A/B testing variations where some modules may not be available 6. IndexedDB persistence: Request storage persistence and add delay in destroy() to allow pending writes to flush, preventing session corruption especially for Business WhatsApp accounts Fixes: pedroslopez#5717, pedroslopez#5685, pedroslopez#3971 See also: PR pedroslopez#5748, PR pedroslopez#3972, PR pedroslopez#5738
BenyFilho
added
the
waiting for testers
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
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.
Problem: ExposeStore can throw Requiring unknown module "WAWebSetPushnameConnAction" in certain WhatsApp Web sessions, notably during reconnection/restore flows when using the LocalAuth strategy. This aborts Store injection, so window.WWebJS is never initialized and the ready event does not fire. As a result, downstream calls that rely on the injected API (e.g., Client.getChatById) can fail, leading to errors such as ERROR (sendMessage) Evaluation failed: TypeError: Cannot read properties of undefined (reading 'getChat'), which also breaks operations like sendMessage. In practice, the issue often appeared “fixed” only after forcing a fresh login by clearing the saved session (removing the cached auth) and re-scanning the QR code.
Fix: Guard the WAWebSetPushnameConnAction require with try/catch, and only attach Settings.setPushname when the module is available and exposes a function.
Impact: Prevents a hard initialization failure while preserving existing behavior when the module exists. This makes startup more resilient across varying WhatsApp Web builds without changing functional paths for environments where WAWebSetPushnameConnAction is present.
How tested: Reproduced the failure on a session where the module was missing (authenticated fires, but ready does not; window.WWebJS is absent; getChatById fails), specifically during a LocalAuth reconnection attempt. After the patch, ready consistently fires, window.WWebJS is present, getChatById succeeds, and sendMessage works as expected without requiring session deletion or QR re-scan.