sendMessage returns a valid message ID but no ACK; message remains "Waiting for this message" and session later logs out

[qwleoz]

Issue Description

After recent WhatsApp Web updates, client.sendMessage() intermittently returns a valid message object and serialized ID, but the message is not successfully delivered.

The failure has been reproduced both with a minimal probe and with the regular application:

1. A freshly linked LocalAuth session initially sends messages normally.
2. Successful messages receive ACK 1, followed by ACK 2/3.
3. After some time, sendMessage() still resolves and returns a valid message ID.
4. No message_ack event is received for that ID, including ACK 1.
5. The affected message appears as "Waiting for this message. This may take a while."
6. client.getState() may still report CONNECTED.
7. The session later becomes invalid and WhatsApp Web navigates to:

https://web.whatsapp.com/?post_logout=1

Relinking the session from scratch only resolves the problem temporarily.

This is not merely an application-side SEND-OK interpretation: the application now treats the return from sendMessage() only as SEND-RETURNED and waits up to 60 seconds for ACK 1. The failed messages never receive it.

Relevant Log Sequence

[SEND-TRY] state=CONNECTED
[SEND-RETURNED] msgId=<valid serialized ID>; waiting for ACK 1
[STATE] CONNECTED
[SEND-UNVERIFIED] sendMessage returned <same ID>, but ACK 1 was not received within 60000ms

Immediately preceding messages in the same session received ACK 1, 2 and 3 normally.

During the subsequent restart, the captured page diagnostics showed:

{
  "url": "https://web.whatsapp.com/?post_logout=1",
  "readyState": "loading"
}

Puppeteer then reported Execution context was destroyed while WhatsApp Web was navigating. This appears to be a consequence of the logout/navigation, rather than the initial sending failure.

Steps To Reproduce

1. Create a client using LocalAuth.
2. Link a fresh session using QR.
3. Send periodic text messages to a dedicated test group.
4. Record the returned message ID and all message_ack events.
5. Initially, messages receive ACK 1/2/3.
6. Eventually, sendMessage() may return a valid ID without any ACK.
7. Check the affected message on linked devices.
8. Continue monitoring the page/session; it may redirect to ?post_logout=1.

The failure is intermittent and may require several hours.

Code Sample

const { Client, LocalAuth } = require('whatsapp-web.js');

const client = new Client({
    authStrategy: new LocalAuth({ clientId: 'ack-test' })
});

const groupId = 'REPLACE_WITH_TEST_GROUP_ID@g.us';

client.on('ready', async () => {
    console.log('WhatsApp Web version:', await client.getWWebVersion());

    const sendProbe = async () => {
        const message = await client.sendMessage(
            groupId,
            `ACK test ${new Date().toISOString()}`
        );

        console.log('SEND-RETURNED:', message.id._serialized);
    };

    await sendProbe();
    setInterval(sendProbe, 15 * 60 * 1000);
});

client.on('message_ack', (message, ack) => {
    console.log('ACK:', ack, 'ID:', message.id._serialized);
});

client.on('disconnected', reason => {
    console.log('DISCONNECTED:', reason);
});

client.initialize();

Environment

• Account type: Standard
• Authentication: LocalAuth
• whatsapp-web.js: 1.34.7
• WhatsApp Web version observed: 2.3000.1043332421
• Browser: Chromium 146.0.7680.31
• Node.js: 20.19.5
• OS: Ubuntu 22.04.5 LTS
• Primary phone: Android 14
• Primary phone WhatsApp: 2.26.27.85

The installed package is npm release 1.34.7 with a local patch-package equivalent of PR #201848 for the $1 serialized-ID compatibility change. The earlier PR #201832 fork is no longer installed.

The $1 patch fixes the previous r: r exception, but it does not prevent this missing-ACK / waiting-message / logout sequence.

Additional Isolation

The same missing-ACK behavior occurred in a minimal probe without Firestore event processing.

During application testing, these operations were also disabled:

• getChats()
• getChatById()
• msg.getChat()
• sendSeen()
• Chat synchronization

Therefore, the failure is not dependent on those operations.

Possibly Related

Issue #201770 reports the same unexpected LOGOUT navigation to
?post_logout=1 using whatsapp-web.js 1.34.7 and Chromium 146.

The present report adds a preceding observable failure: sendMessage()
returns a valid ID, but ACK 1 stops arriving before the session is logged out.

[qwleoz]

I rewrote the report with the latest isolated reproduction and diagnostic evidence. The current failure is specifically that sendMessage() returns a valid message ID but ACK 1 never arrives; the session subsequently redirects to ?post_logout=1.

[qwleoz]

New evidence after a fully clean relink:

• All linked devices were removed from the primary phone.
• The LocalAuth directory was deleted.
• The freshly linked session initially sent messages successfully with ACK 1/2.
• After approximately 17 minutes, sendMessage() started throwing
  Failed to find row in chat table.
• A later send returned a valid message ID but never received ACK 1.
• The preserved LocalAuth session subsequently loaded
  https://web.whatsapp.com/?post_logout=1.
• The application never calls client.logout() and the recovery path preserves
  the LocalAuth directory.

[qwleoz]

Additional isolation: Puppeteer 25 / Chrome 150

I performed additional isolated tests using the dependency update proposed in #201814.

Environment

• whatsapp-web.js: 1.34.7
• Local patch equivalent to fix: tolerate WhatsApp Web renaming the message key _serialized to $1 #201848 still applied
• Node.js: 22.23.1
• Puppeteer / Puppeteer Core: 25.3.0
• Chrome for Testing: 150.0.7871.24
• WhatsApp Web observed: 2.3000.1043451071
• OS: Ubuntu 22.04.5 LTS
• Test application: minimal probe only, without Firestore processing, chat synchronization, getChats(), getChatById(), sendSeen(), or application send queues

Full Chrome with modern headless mode

The client authenticated successfully and initially sent messages normally. Messages received ACK 1, 2, and 3.

Example:

[SEND-TRY] state=CONNECTED
[ACK] ... ack=1
[SEND-OK] ...
[ACK-CONFIRMED] ... ack=1
[ACK] ... ack=2
[ACK] ... ack=3

The Chrome process later terminated and Chrome Crashpad generated a minidump. This particular run occurred while the root filesystem had only approximately 535 MB free, so I do not consider the browser crash conclusive by itself.

The filesystem was subsequently cleaned and now has approximately 5.2 GB free. The VM also had approximately 6.5 GB available RAM, low system load, almost unused swap, sufficient /dev/shm, and no OOM or killed-process entries in the kernel journal.

Fresh LocalAuth session with Chrome Headless Shell 150

After correcting the disk usage, I tested the official chrome-headless-shell 150.0.7871.24 installed by Puppeteer 25.

I moved the previous authentication directory aside, generated a completely fresh LocalAuth session, and scanned a new QR.

The new session was logged out before reaching ready:

[QR] Published successfully
[DISCONNECTED] LOGOUT
[HOLD] Test session preserved
[DISCONNECTED] LOGOUT
Execution context was destroyed, most likely because of a navigation

WhatsApp Web then returned to the QR flow. The Execution context was destroyed errors occurred after the logout/navigation and again appear to be a consequence rather than the initial cause.

This shows that upgrading only Node, Puppeteer, and Chrome does not resolve the unexpected logout. A newly linked minimal session can still be invalidated before ready, with healthy VM resources and no application-level message processing.

For comparison, the same WhatsApp account remained connected for several hours in regular Chrome 150 on Windows using the official WhatsApp Web interface.

[qwleoz]

Workaround update

I was able to keep the bot operational for more than 12 hours with successful real sends and ACK 1/2/3 using the following environment:

• whatsapp-web.js: 1.34.7
• Node.js: 22.23.1
• Puppeteer / puppeteer-core: 25.3.0
• Chrome for Testing: 150.0.7871.24
• Chrome mode: headful (headless: false)
• Display: Xvfb (DISPLAY=:99)
• OS: Ubuntu 22.04.5 LTS
• WhatsApp Web observed: 2.3000.1043454487
• The local $1 serialized-ID compatibility patch mentioned in the original report remains applied.

The application is still running in a reduced mode with the following operations disabled:

• getChats()
• getChatById()
• msg.getChat()
• sendSeen()
• Chat synchronization

Passive presence remains enabled without opening chats.

During this period, the page performed one internal reload/reinitialization. It emitted:

TypeError: null is not a function
[storage] storage bucket persistence denied
READY event fired again

The application ignored the duplicate ready initialization, remained CONNECTED, and subsequent messages were delivered successfully with ACK 1/2/3.

Before this working configuration, tests using headless modes still reproduced failures, including a hanging sendMessage(), browser disconnection, and LOGOUT. However, several variables changed together (Node.js, Puppeteer, Chrome and headless mode), so this does not prove that headless mode alone is the root cause.

This should therefore be considered a workaround and an additional isolation result, not confirmation that the underlying whatsapp-web.js issue is fixed.