Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The channels.whatsapp.start-account startup phase blocks the Node event loop for ~30–40s on a single tick, causing an event_loop_delay liveness warning and tripping WhatsApp's keepalive timeout, which forces an immediate reconnect that re-runs the same expensive bootstrap (reconnect storm).

Steps to reproduce

1. Run OpenClaw 2026.5.4 on Windows 11 with a long-lived WhatsApp account paired (existing Baileys session, large signal store).
2. Trigger or wait for a WhatsApp socket reconnect (e.g. transient network blip, gateway restart, or openclaw channels login --channel whatsapp --account default).
3. Observe the gateway diagnostic emitted during startup of the WhatsApp account.

Reproduced live at 20:38 local with the diagnostic below; the same start-account phase reappears every time the WA listener is brought back up after being idle for hours.

Expected behavior

channels.<id>.start-account should never block the event loop long enough to trip the liveness warning (eventLoopDelayMaxMs < 1000ms) or the upstream WhatsApp keepalive (~30s), so a single reconnect completes in one bootstrap cycle without cascading further reconnects. Other channels (Telegram, Signal) bootstrap in <1s on the same gateway and do not exhibit this pattern.

Actual behavior

Single tick of work inside start-account blocks the loop for ~40s. The diagnostic line:

20:38:10 [diagnostic] liveness warning: reasons=event_loop_delay interval=57s eventLoopDelayP99Ms=33.8 eventLoopDelayMaxMs=40064 eventLoopUtilization=0.744 cpuCoreRatio=0.793 active=1 waiting=0 queued=1 phase=channels.whatsapp.start-account recentPhases=sidecars.restart-sentinel:0ms,sidecars.subagent-recovery:2ms,sidecars.main-session-recovery:5ms,post-attach.update-sentinel:0ms,sidecars.session-locks:30ms,post-ready.maintenance:732ms work=[active=agent:main:whatsapp:direct:+14374222496(processing,q=1,age=41s) queued=agent:main:whatsapp:direct:+14374222496(processing,q=1,age=41s)]

While the loop is blocked, the WhatsApp WebSocket keepalive misses its window and the underlying provider drops the socket, which then auto-reconnects and re-enters start-account — looping until the bootstrap finally completes (typically one or two extra cycles, ~60–80s of unresponsiveness).

The relevant frame in the bundled output (dist/server-channels-CP_Np2uZ.js:401) is just a Promise.resolve().then() around plugin.gateway.startAccount(...) — the long synchronous chunk lives inside the WhatsApp plugin's startAccount (Baileys auth-state load + replay), so chunking/yielding (e.g. await new Promise(setImmediate) between heavy steps, or moving the auth-state replay to a worker_thread) needs to happen inside that plugin, not at the call site.

OpenClaw version

2026.5.4

Operating system

Windows 11 (10.0.26200, x64)

Install method

npm global (npm install -g openclaw, Node v24.15.0)

Model

github-copilot/claude-opus-4.7

Provider / routing chain

openclaw -> github-copilot

Additional provider/model setup details

Provider/model is unrelated to the symptom — start-account runs inside the gateway/channel-plugin host before the agent runtime is involved. Same gateway hosts Telegram + webchat with no event-loop warnings.

Logs, screenshots, and evidence

20:38:10 [diagnostic] liveness warning: reasons=event_loop_delay interval=57s eventLoopDelayP99Ms=33.8 eventLoopDelayMaxMs=40064 eventLoopUtilization=0.744 cpuCoreRatio=0.793 active=1 waiting=0 queued=1 phase=channels.whatsapp.start-account recentPhases=sidecars.restart-sentinel:0ms,sidecars.subagent-recovery:2ms,sidecars.main-session-recovery:5ms,post-attach.update-sentinel:0ms,sidecars.session-locks:30ms,post-ready.maintenance:732ms work=[active=agent:main:whatsapp:direct:+14374222496(processing,q=1,age=41s) queued=agent:main:whatsapp:direct:+14374222496(processing,q=1,age=41s)]

Bundled call site (for reference, not a fix location):

// dist/server-channels-CP_Np2uZ.js  (~line 401)
const trackedPromise = Promise.resolve().then(() =>
  measureStartup(`channels.${channelId}.start-account`,
    () => startAccount({ cfg, accountId: id, account, runtime, abortSignal: abort.signal, log, ... })
  )
)

The fix needs to land inside the bundled WhatsApp plugin's startAccount implementation (Baileys-side auth-state load / signal-store rehydrate).

Impact and severity

• Affected: any user with a non-trivial WhatsApp session on 2026.5.4 — fires every time the WA listener bootstraps.
• Severity: High. During the 40s+ event-loop stall the entire gateway is unresponsive: no message routing, no tool calls, no diagnostics. Other unrelated sessions (webchat, Telegram) freeze in lockstep.
• Frequency: Every observed reconnect (3/3 today). Once stable the listener stays up, so users who never reconnect won't notice; users with flaky links or who restart the gateway hit it every time.
• Consequence: Missed inbound WhatsApp messages during the stall window, cron job runs delayed (waiting=0 queued=1 in the diagnostic shows queued work), and stuck processing,q=1,age=41s work items on the affected session.

Additional information

• Related upstream patch already shipped in patches/@[email protected] addresses media-stream races but not the auth-state bootstrap cost.
• Workaround: full gateway restart (gateway restart) or openclaw channels logout/login --channel whatsapp --account default resets the session so the next start-account is cheaper, but the underlying expensive synchronous step remains.
• This is the same code path that has historically produced silent listener drops (see local notes: whatsapp-relogin cron auto-revive failures). Suspect the two are related — when the bootstrap blocks long enough, the watchdog cron itself can't run because the loop is stuck.