openclaw - 💡(How to fix) Fix [Bug]: WhatsApp inbound handler dead after 408 reconnect cycle — watchdog detects but reconnect doesn't restore (2026.4.26 regression) [1 comments, 1 participants]

Summary

After upgrading to 2026.4.26 (which included WhatsApp stability improvements), the WhatsApp inbound handler enters a silent failure loop within <24 hours. The built-in watchdog correctly detects the problem (app-silent) but the 499 reconnect it triggers does not restore inbound message delivery. This persists across multiple full gateway restarts.

Related: #66920, #63855 — same symptom (silent inbound message loss with "Listening" logged), but those were filed against 2026.4.8–2026.4.14. This reports the issue persisting/regressing in 2026.4.26.

Environment

• OpenClaw: 2026.4.26 (be8c246)
• Node: v25.8.2
• macOS 26.2 (arm64)
• Two WhatsApp accounts (default + secondary), dual-account setup
• sleep 0, disksleep 0, displaysleep 0 confirmed — not a system sleep issue

Observed Behavior

Timeline (all times UTC-4)

1. 10:39 — Last successful inbound message received (group message on default account)
2. 11:53 — One more inbound, then silence
3. 12:27–12:29 — Built-in watchdog starts warning: ⚠️ web gateway heartbeat - no messages in 30+ minutes (correct detection)
4. 13:20 — Gateway SIGTERM restart (watchdog-triggered)
5. After 13:20 — WhatsApp connects, logs "Listening for personal WhatsApp inbound messages" on both accounts
6. messagesHandled: 0, lastInboundAt: null — zero inbound messages processed after reconnect
7. 15:20, 17:20, 19:20 — Three more full gateway restarts, same result each time
8. 21:05 — Manual restart finally restored connectivity (both accounts connected)

Key log patterns

Watchdog fires correctly but reconnect does not restore inbound:

watchdogReason: "app-silent"
minutesSinceAppActivity: 120
lastInboundAt: null
messagesHandled: 0

408 disconnects still occurring throughout the day:

WhatsApp Web connection closed (status 408). Retry 1/12 in 2.37s…

Secondary account sends fail with forbidden:

failed to send via web session — err: "Error: forbidden"
No active WhatsApp Web listener (account: secondary)

After each restart, "Listening" logged but no inbound ever arrives:

[whatsapp] Listening for personal WhatsApp inbound messages.
[whatsapp] Listening for personal WhatsApp inbound messages.

(Two lines = two accounts connecting, but messagesHandled stays at 0)

Expected Behavior

• After watchdog-triggered reconnect or gateway restart, inbound messages should be delivered
• The 408 → reconnect cycle should fully re-register message event handlers
• messagesHandled should increment when messages are sent to bound groups

Analysis

The new built-in watchdog (checking minutesSinceAppActivity) is a great improvement over the old behavior — it correctly identifies the stale connection. However, the reconnect path (499 → fresh connection → "Listening") appears to not fully restore the inbound message pipeline. The connection is established but the event handler registration is incomplete.

This may be the same underlying Baileys event handler registration issue from #66920/#63855 surviving the fix — the reconnect re-establishes the WebSocket but does not re-register the messages.upsert (or equivalent) listener.

Reproduction

1. Configure dual-account WhatsApp with group allowlists
2. Let the gateway run — 408 disconnects will occur naturally
3. After the first app-silent watchdog cycle (~2 hours), observe that messagesHandled: 0 and lastInboundAt: null persist
4. Send a message to a bound group — it will not appear in logs
5. Restart gateway — connection logs "Listening" but inbound remains dead
6. Eventually a restart may restore it (non-deterministic — took 5 restart cycles in our case)

Workaround

Repeated full gateway restarts eventually restore the connection (non-deterministic).