decryptWithSessions blocks Node.js event loop for 10-52s with stale sessions → 408 disconnects

[bobrenze-bot]

Summary

SessionCipher.decryptWithSessions() in @whiskeysockets/libsignal-node iterates through all stored sessions synchronously, running full Signal Protocol crypto on each attempt. When there are many stale sessions and messages arrive that fail to decrypt (MessageCounterError: Key used already or never filled), the loop exhausts all sessions before throwing — blocking the Node.js event loop for 10–52 seconds in production.

Impact

This causes a feedback loop that many users will recognise:

1. Event loop blocked → keepalive pings delayed → WA server sends 408 timeout
2. On 408 reconnect, backlog of messages arrives → decryptWithSessions runs again → blocks event loop again → another 408
3. Repeat indefinitely

The 408 disconnect issues in this repo are frequently caused by this — not by network conditions.

Measured impact (production, Node 20):

• eventLoopDelayP99Ms: 52,244ms → 134ms after fix (390× improvement)
• WebSocket 408 disconnects: every 2 min → every 10–20 min after fix
• All async operations on the same event loop (HTTP requests, timers, other WebSocket connections) stalled for the duration

Root Cause

In node_modules/@whiskeysockets/libsignal-node/src/session_cipher.js, decryptWithSessions is a for...of loop with no await between iterations that would yield to the event loop:

async decryptWithSessions(data, sessions) {
    const errs = [];
    for (const session of sessions) {
        let plaintext;
        try {
            plaintext = await this.doDecryptWhisperMessage(data, session); // CPU-heavy crypto
            // ...
        } catch(e) {
            errs.push(e);
        }
    }
    // ...
}

doDecryptWhisperMessage is CPU-intensive JS (elliptic curve crypto). await on it does not yield to the event loop — it only yields to microtasks. With 10–50 sessions × CPU crypto per session, the event loop is blocked until the entire loop completes.

Fix

Add a setImmediate yield before each attempt. This allows pending macrotasks (timers, I/O callbacks, keepalive pings) to run between session attempts:

async decryptWithSessions(data, sessions) {
    if (!sessions.length) {
        throw new errors.SessionError("No sessions available");
    }
    const errs = [];
    for (const session of sessions) {
        // Yield to event loop between attempts so keepalive timers can fire.
        // Without this, N sessions × crypto blocks the event loop for tens of seconds.
        await new Promise(resolve => setImmediate(resolve));
        let plaintext;
        try {
            plaintext = await this.doDecryptWhisperMessage(data, session);
            session.indexInfo.used = Date.now();
            return { session, plaintext };
        } catch(e) {
            errs.push(e);
        }
    }
    console.error("Failed to decrypt message with any known session...");
    for (const e of errs) {
        console.error("Session error:" + e, e.stack);
    }
    throw new errors.SessionError("No matching sessions found for message");
}

The fix is one line. It doesn't change decryption logic or session ordering — it just lets the event loop breathe between attempts.

Upstream

This fix should land in @whiskeysockets/libsignal-node. An issue has been filed there: WhiskeySockets/libsignal-node#18

Until it's merged, users can patch the file locally at:
node_modules/@whiskeysockets/libsignal-node/src/session_cipher.js

Reproduction

Any Baileys app with multiple stale Signal sessions will hit this. Trigger by:

1. Run Baileys with --inspect and a CPU profiler
2. Send a message from a device not in the active session
3. Observe the event loop block in the profiler / eventLoopUtilization diagnostic

[kaikybrofc]

Implemented a mitigation for this in my fork and prepared a PR to master.

What this patch does:

• Applies a runtime patch to libsignal.SessionCipher#doDecryptWhisperMessage
• Adds await new Promise(resolve => setImmediate(resolve)) before each decrypt attempt
• This yields to the event loop between CPU-heavy session decrypt attempts, reducing keepalive starvation / 408 loops when stale sessions exist

Notes:

• Behavior/order of decryption attempts is preserved
• Patch is guarded and applied once
• If the internal method signature changes upstream, it logs and safely skips patching

Validation done on branch:

• npm test: PASS (16 suites, 174 tests)
• npm run lint: PASS (warnings only, no errors)
• npm run test:e2e: fails in setup timeout (beforeAll), environment/auth dependent

If preferred, I can move this to libsignal-node directly once upstream issue WhiskeySockets/libsignal-node#18 is merged strategy-wise.

[alessandropcostabr]

Production data: second event-loop starvation vector via chats.delete burst

Sharing production observations that complement the decrypt starvation root cause described here.

Environment: Node.js 22.21.0, single Baileys worker process managing 12 simultaneous WhatsApp accounts (PM2 fork mode), ~3,000–7,000 messages/day across all accounts.

Observed pattern

We capture unhandled Baileys events via a sniff layer (sock.ev.emit intercept). Across 10 days of production logs, we observed a recurring burst pattern on one account (high group activity, ~20 active groups):

2026-04-25T00:03:57Z [account:14] chats.delete   ← burst start
2026-04-25T00:03:57Z [account:14] chats.delete
... (100+ events) ...
2026-04-25T00:04:16Z [account:14] chats.delete   ← burst end (~15 min window)

Same pattern recurred on 23/04, 25/04, and 30/04 — always around midnight UTC-3, consistent with a post-reconnect WA state sync/cleanup cycle. The sample field in each event contains numeric indices (["0","1","2",...]) rather than JIDs, suggesting WA is deleting positional entries from a local chat list rather than specific conversations.

Why this is relevant to this issue

Even with the setImmediate yield fix applied to decrypt attempts (PR #2523), a burst of 100+ chats.delete events still queues 100+ synchronous handler invocations back-to-back on the event loop. With 12 accounts, if multiple reconnect simultaneously (common after a keepalive loss triggered by the very decrypt starvation this issue describes), the combined burst can produce 500–1,000 queued events before any I/O callbacks can run — perpetuating keepalive delays even after the decrypt fix is applied.

The feedback loop we observe:

1. Stale session decrypt starvation → keepalive missed → 408 disconnect
2. On reconnect, WA triggers state sync → chats.delete burst (100+ events)
3. Event queue saturated → next keepalive delayed again → another 408
4. Repeat

Proposed complement to PR #2523

A debounced/batched handler for chats.delete that coalesces rapid-fire events within a short window (e.g. 500ms) before emitting, rather than N individual events. For consumers that don't use the Baileys chats store, this would be transparent. For those who do, the batched form (chats.delete with the full ID list) is equivalent.

Happy to test any fix for this on our production setup and report back.

[alessandropcostabr]

Correction to my previous comment

I need to correct the interpretation of the sample field in my comment above.

The numeric indices ["0","1","2",...] in the sample are not WA positional delete entries — they are an artifact of a bug in our sniff serializer. Our code calls Object.keys(data[0]) to summarize the event, but chats.delete emits an array of JID strings, not objects. Object.keys("5511999...@s.whatsapp.net") returns character position indices, not meaningful data.

What remains accurate:

• The burst pattern is real: 100+ separate chats.delete events (each count: 1) fired in ~15 minutes
• The timestamps and recurrence pattern (23/04, 25/04, 30/04) are real
• The event count contributing to the feedback loop is real

What was wrong:

• The interpretation "WA deletes by position index" is incorrect — we simply couldn't see the actual JIDs due to our serializer bug

The core observation stands: a burst of 100+ individual chats.delete events still queues 100+ handler invocations, contributing to event loop pressure. The JIDs being deleted are normal chat JIDs (we just couldn't read them).

Apologies for the noise.

[kaikybrofc]

Implemented this in PR #2523 (latest commit: 7b32ac8).

What was added:

• Debounced/coalesced chats.delete emissions in makeEventBuffer using a 500ms window.
• JID deduplication inside the debounce window (Set).
• Ordering safety: pending debounced deletes are flushed before non-chats.delete events to avoid reordering (update emitted before delete).

Tests:

• Added src/__tests__/Utils/event-buffer.test.ts
• Covers: (1) burst coalescing into a single chats.delete emission, (2) flushing pending deletes before another event to preserve order.
• Local run passed (npm test -- src/__tests__/Utils/event-buffer.test.ts --runInBand).

[Santosl2]

@jlucaso1 @purpshell

[alessandropcostabr]

Update: setImmediate yield patch tested and working on rc.11

Following up on our earlier contribution (session starvation data from production). We've now tested a setImmediate yield patch on rc.11 and can confirm it works without breaking inbound or outbound.

Patch applied

We wrapped both decryptMessage and decryptGroupMessage calls in decode-wa-message.js with a setImmediate yield to allow the event loop to breathe between decryptions:

// BEFORE:
msgBuffer = await repository.decryptMessage({ jid, type: e2eType, ciphertext: content });

// AFTER:
msgBuffer = await new Promise((resolve, reject) => {
    setImmediate(async () => {
        try {
            resolve(await repository.decryptMessage({ jid, type: e2eType, ciphertext: content }));
        }
        catch (err) { reject(err); }
    });
});

Same pattern applied to decryptGroupMessage (skmsg case).

Test results on rc.11

Test	Result
Inbound text message	OK
Inbound image	OK
Inbound audio	OK
Outbound text + media	OK
ACK delivery (double check)	OK
Patch isolated test (only this patch, no others)	OK

We're running this in production (dev environment) as part of our rc.9 to rc.11 migration. After 3+ hours of uptime with this patch:

• Memory: 152 MB (stable, no growth)
• Errors: 0
• Ghost sessions: 0
• Disconnects: 1 (normal 428 restartRequired, auto-reconnected)

Notes

• The setImmediate approach adds negligible latency per message (sub-ms) but prevents the 10-52s event loop blocks we documented in the original issue
• We applied this via patch-package with --error-on-fail to ensure it's always applied on install
• The await on the Promise wrapper preserves the sequential decrypt behavior - it just yields between calls
• rc.11's new event buffer (ev.buffer() / ev.flush()) is compatible with this approach

Environment

• Node.js 22.21.0
• Baileys 7.0.0-rc.11
• Multi-tenant (12 accounts)
• PM2 fork mode

[kaikybrofc]

Atualização das correções enviadas no PR #2523:

• Resolvi o conflito com upstream/master no arquivo de testes de event buffer.
• Mantive os testes de debounce e ordem de chats.delete.
• Mantive também os testes de messaging-history.set com pastParticipants.
• Fiz o merge das duas abordagens no mesmo arquivo de teste, sem perder cobertura.
• Commit aplicado na branch do PR: be32255.

Status atual: a branch do PR já foi atualizada e os conflitos foram resolvidos.

[kaikybrofc]

Complementando o comentário anterior e em referência direta a #2520 (comment):

As correções adicionais já foram aplicadas na branch do PR #2523, incluindo a resolução de conflitos com upstream/master e a unificação dos testes de event buffer para preservar cobertura dos cenários de chats.delete e messaging-history.set com pastParticipants.

Também deixei registrado o commit de merge e atualização da branch no comentário mais recente deste issue.