openclaw - 💡(How to fix) Fix WhatsApp 408 disconnects in 2026.4.27 are caused by event-loop blocking up to 100s, not Baileys [1 comments, 2 participants]

Summary

The chronic WhatsApp status 408 — Connection Terminated disconnects we see in 2026.4.27 (also 2026.4.24) are not a Baileys bug — the new liveness diagnostic subsystem in 2026.4.27 shows the OpenClaw gateway's Node event loop is being blocked for tens of seconds at a time. While the loop is blocked, Baileys' keepalive ping cannot fire, so WhatsApp Web closes the socket at ~60s with HTTP 408. Any in-flight outbound reply is dropped (no replay).

Environment

• OpenClaw 2026.4.27 (cbc2ba0) (also reproduced on 2026.4.24)
• Bundled @whiskeysockets/[email protected] (this is the npm latest)
• Node 22.22.2, Linux 6.8.0-106-generic, Contabo VPS — 4 cores / 7.8 GB / load 1.09
• Single WhatsApp account, gateway in local mode, loopback bind
• Model: openai-codex/gpt-5.5

Capacity is not the issue. The event loop is being blocked synchronously.

Evidence — liveness warnings from a single 15-min window today

16:38:22  eventLoopDelayMaxMs=5226     util=0.188  active=0 queued=0  (startup)
16:40:26  eventLoopDelayMaxMs=100059   util=1.000  active=0 queued=0  ★ 100s block
16:43:31  eventLoopDelayMaxMs=7222     util=0.306  active=1 queued=1
16:48:41  eventLoopDelayMaxMs=97039    util=0.992  active=0 queued=0  ★ 97s block
16:53:00  eventLoopDelayMaxMs=32799    util=0.905  active=1 queued=1  ★ 33s block

Notice the active=0 queued=0 rows: the loop is blocked even when the agent runtime says nothing is in flight, so the cause isn't simply LLM latency.

Symptom timing (deterministic)

Bimodal at ~52-63s and ~103s — consistent with Baileys' default keepAliveIntervalMs (30s) + defaultQueryTimeoutMs (60s) firing during event-loop blocks.

Hypotheses to investigate (the diagnostic subsystem already collects the

data — please surface its async-resource trace alongside the warning)

1. Memory subsystem fallback: chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. — does the FTS fallback do a synchronous scan on each agent turn?
2. Session transcript loading: a 6.6 MB / 386-line .jsonl was correlating with the worst blocks. Is loadSessionTranscript synchronous JSON parsing on the main thread?
3. Plugin runtime-deps re-extraction at startup (we hit the 100s block at 16:40, two minutes after process start) — extracting tarballs sync?
4. There is also a stale-tree GC bug: plugin-runtime-deps/ accumulates a directory per OpenClaw version forever. After two upgrades we had 3.5 GB of stale trees alongside the active one. Manual rm -rf was needed.

Asks

1. Identify and fix what blocks the event loop. The diagnostic subsystem already detects it — please log the async-resource at the time of the block.
2. On WhatsApp socket close after a queued outbound, replay the reply on reconnect rather than dropping it.
3. Expose Baileys timeout/keepalive options in channels.whatsapp so operators can mitigate without waiting on a fix.
4. Garbage-collect stale plugin-runtime-deps/openclaw-<version>-* trees on upgrade.

Workaround in use

Hourly cron resets the direct-DM session transcript when it crosses size or token-pct thresholds, keeping LLM call latency short enough that replies sometimes land before the next 408. This is operationally noisy and shouldn't be needed.