Skip to content

Instance stays "open" but stops receiving messages after "stream errored out" (ack class="status") — Baileys #2858, fix with 3 lines #2778

New issue
New issue
Open
Open
Instance stays "open" but stops receiving messages after "stream errored out" (ack class="status") — Baileys #2858, fix with 3 lines#2778
Labels
bugSomething isn't working

Description

@innovateai2025
innovateai2025
opened on Nov 4, 2026

Welcome!

  • Yes, I have searched for similar issues on GitHub and found none.

What did you do?

Running evoapicloud/evolution-api:v2.3.7 (Baileys 7.0.0-rc.9), Postgres + Redis, ~30 QR instances with Chatwoot integration. Nothing special: instances were just running normally.

What did you expect?

Instances that show connectionStatus "open" keep receiving incoming messages: they are stored in the Message table and the messages.upsert webhook is fired.

What did you observe instead of what you expected?

Some instances stay "open" but stop receiving: messages arrive on the phone, but nothing is stored in the Message table and no webhook fires. Other instances on the same server keep working.

  • Restarting the instance (/instance/restart) does NOT fix it.
  • Restarting the whole container does NOT fix it.
  • Logout + new QR fixes it, until it happens again (in one case, less than 3 hours later).

Each episode starts with a Baileys "stream errored out" whose node is an ack with class="status" (see logs below). Within 1-3 seconds, the affected instance auto-reconnects (its Instance.updatedAt changes) and from then on it receives nothing.

Note: this is not the same as #2773 (disappearing messages). Here ALL incoming messages stop for the instance, regardless of the contact.

Screenshots/Videos

No response

Which version of the API are you using?

2.3.7

What is your environment?

Docker

Other environment specifications

Docker image evoapicloud/evolution-api:v2.3.7 (Baileys 7.0.0-rc.9), PostgreSQL 17, Redis 7 (CACHE_REDIS_ENABLED=true), Chatwoot integration enabled, ~30 WHATSAPP-BAILEYS (QR) instances on the same server.

If applicable, paste the log output

{"level":50,"msg":"stream errored out",
 "reasonNode":{"tag":"ack","attrs":{"class":"status","type":"text","id":"AC9087..."}},
 "fullErrorNode":{"tag":"stream:error","attrs":{},
   "content":[{"tag":"ack","attrs":{"class":"status","type":"text","id":"AC9087..."}}]}}

type can be text or media. We saw 3-9 of these per hour on our server, each one followed by an instance auto-reconnecting.

Additional Notes

Root cause: Baileys issue #2858 (WhiskeySockets/Baileys#2858). Since late September 2026 WhatsApp sends top-level <status> stanzas (Status updates) that Baileys never acks. ~50 min later the server closes the stream with the missing ack; on reconnect the same <status> is redelivered and never acked, so the session stays "open" without receiving. The upstream fix (PR #2866) is not released yet.

Fix: in node_modules/baileys/lib/Socket/messages-recv.js, right after the CB:notification handler (around line 1220 in rc.9), add:

ws.on('CB:status', (node) => {
    sendMessageAck(node).catch(error => onUnexpectedError(error, 'acking status stanza'));
});

A plain ack, no error code (a NACK keeps the stanza pending). Evolution ignores Status (readStatus: false), so nothing is lost.

To make it persistent, we build a derived image instead of editing the container:

FROM evoapicloud/evolution-api:v2.3.7
COPY patch-status.cjs /tmp/
RUN node /tmp/patch-status.cjs /evolution/node_modules/baileys \
 && node --check /evolution/node_modules/baileys/lib/Socket/messages-recv.js

Our script inserts those lines and fails the build if the Baileys version is not exactly 7.0.0-rc.9 or the anchor code is not found, so it can't silently break on upgrade. Happy to share it.

Result: deployed on two servers. Zero "stream errored out" with class "status" since then, and an instance that had been broken for 14+ hours started receiving again after the restart, without re-pairing.

Suggestion: bump Baileys once #2866 is released, or ship this handler via patch-package in the meantime.

Activity

  1. innovateai2025
    added
    bugSomething isn't working
    on Nov 4, 2026

  2. Wellers0n commented on Nov 5, 2026

    @Wellers0n
    Wellers0n
    on Nov 5, 2026

    I’m also experiencing this bug.

  3. guilherme-skillsoft commented on Nov 5, 2026

    @guilherme-skillsoft
    guilherme-skillsoft
    on Nov 5, 2026

    Kudos for the fix!

    Using on 2 different instances and no problems since patching it.

  4. jcalencar commented on Nov 5, 2026

    @jcalencar
    jcalencar
    on Nov 5, 2026

    same bug here

  5. MarToxAk commented on Nov 7, 2026

    @MarToxAk
    MarToxAk
    on Nov 7, 2026

    Opened #2785 with a fix: it backports WhiskeySockets/Baileys#2883 (ack top-level <status> stanzas) through patch-package on develop (Baileys 7.0.0-rc13).

    The same change on the compiled rc.9 inside 2.4.0-rc2 fixed it here: 951 <status> stanzas acked in the first 3 minutes, and the held-back inbound messages were released in about 1 minute. No new QR was needed.

  6. jailtonseguros commented on Nov 7, 2026

    @jailtonseguros
    jailtonseguros
    on Nov 7, 2026

    Estou com esse problema também, vou testa e ver como fica, o de vocês normalizou com esse versão MarToxAk?

  7. julianomatias commented on Nov 9, 2026

    @julianomatias
    julianomatias
    on Nov 9, 2026

    Implementamos e está funcionando. Parabéns

  8. rafaelcosta-BR commented on Nov 9, 2026

    @rafaelcosta-BR
    rafaelcosta-BR
    on Nov 9, 2026

    Same issue here, and the community patch fixed it. Sharing our data in case it helps others.

    Environment: evoapicloud/evolution-api:v2.3.7 (Baileys 7.0.0-rc.9), Postgres 16, Redis 7, Chatwoot integration, Docker.

    Symptoms (6-7 Nov 2026):

    • One instance stopped receiving messages. connectionState kept returning open, but nothing was saved to Message and nothing reached Chatwoot.
    • The log showed stream errored out with reasonNode: {tag: 'ack', attrs: {class: 'status', type: 'media'}} exactly every 3000 s: 20 times in about 16 h.
    • Restarting the container did not help. Logging out and scanning a new QR brought messages back for a few hours only.
    • On a second server (Swarm, same image, 2 instances), both instances had the same class=status drops. One of them stopped receiving for about 5 hours.

    Fix: we applied the ack handler routed through processNode (the approach from WhiskeySockets/Baileys#2883, with the try/catch so an error does not leave the offline queue stuck). It runs as a derived image whose build fails if Baileys is not exactly 7.0.0-rc.9:

    const handleStatus = async (node) => {
    try { await sendMessageAck(node); }
    catch (error) { onUnexpectedError(error, 'acking status stanza'); }
};
// in makeOfflineNodeProcessor's map: ['status', handleStatus]
ws.on('CB:status', async (node) => {
    await processNode('status', node, 'acking status stanza', handleStatus);
});

    Result:

    • Server 1: 0 stream errors in 47 h after the patch (before: 20 in 16 h). Messages are flowing normally, and no new QR was needed when the patched container replaced the old one.
    • Server 2: patched this morning; both instances reconnected in about 1 minute with their saved sessions (no QR), passed the 50-minute mark with 0 stream errors, and the instance that had gone deaf is receiving again.

    Thanks to @innovateai2025 and everyone in WhiskeySockets/Baileys#2858 for the analysis. Hoping #2785 or an official Baileys release lands soon.

  9. codingB0y
    added a commit that references this issue on Nov 9, 2026

    fix(evolution): image with Baileys "status" stanza ack to stop the 50…

    e8af6c5

  10. carlosasjr commented on Nov 10, 2026

    @carlosasjr
    carlosasjr
    on Nov 10, 2026

    Same issue on evoapicloud/evolution-api:v2.3.7 (Baileys 7.0.0-rc.9), confirming the root cause and that #2785's approach works in production.

    Symptoms (9–10 Nov 2026): one instance stopped receiving for ~17h while connectionState stayed open and sending still worked. The instance's message count stayed frozen. A container restart reconnected it (CONNECTED TO WHATSAPP) but nothing was delivered in the following minutes, so restarting does not cure it.

    Fix: derived image from v2.3.7 with the #2883 backport (handleStatus + CB:status + status in the offline map). Within 1 minute of the swap the instance started receiving again and the held backlog (~17h) was fully delivered in ~6 minutes, with no re-pairing (no new QR) and no duplicates on our side.

    Note for anyone patching 2.3.7 (rc.9) rather than develop: rc.9's offline queue loop has no per-node try/catch, so one throwing node (seen here with a w:gp2 notification) stops the backlog recovery. rc13 already wraps it (offline-node-processor.ts), so this only matters for 2.3.x backports.

    Could #2785 get a review from the maintainers? It's currently blocked and many users here are running it as a community patch. A 2.3.8 with this fix would help everyone on the stable line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions