Description

WhatsApp group inbound messages silently stop being delivered after prolonged 408 WebSocket disconnect/reconnect cycles. Direct messages (DMs) continue to work, and outbound delivery is unaffected. The gateway logs "Listening for personal WhatsApp inbound messages" on each reconnect, but no group messages arrive.

A full gateway restart restores group inbound immediately.

Environment

• OpenClaw: 2026.4.14 (also observed on 2026.4.11)
• Node: v25.8.2
• macOS 26.2 (arm64)
• Baileys (bundled with OpenClaw)
• Two WhatsApp accounts connected simultaneously (dual-account setup)

Steps to Reproduce

1. Configure WhatsApp with group bindings (allowlist groups)
2. Let the gateway run for several hours with normal 408 keepalive timeout cycles (~every 16 minutes)
3. After some number of 408 disconnect/reconnect cycles, send a message to a bound group
4. Message is silently dropped — no inbound log entry, no error

Observed Behavior

Pre-2026.4.12 (e.g. 2026.4.11)

• After prolonged 408 cycling: both group inbound AND DM inbound die
• Outbound continues working
• Gateway logs "Listening for personal WhatsApp inbound messages" on every reconnect

Post-2026.4.12 (2026.4.14)

• After prolonged 408 cycling: only group inbound dies
• DM inbound continues working (confirmed with multiple DMs arriving throughout the day)
• Outbound continues working
• Gateway logs "Listening for personal WhatsApp inbound messages" on every reconnect

The 2026.4.12 connection ownership centralization fix improved DM resilience across reconnect cycles, but did not fix the group message subscription degradation.

Evidence (2026-04-14, version 2026.4.14)

Timeline:

• 11:57 AM — Gateway restarted (update applied)
• 12:08 PM — Group inbound message received ✅ (test message)
• 12:29 PM onward — 408 reconnect cycles every ~16 min (continuous through 9 PM)
• Afternoon — Multiple DMs received on both accounts ✅
• Afternoon — Multiple outbound messages sent successfully ✅
• Afternoon — Multiple messages sent to the same group by the user → zero inbound logged ❌

Log excerpt (post-restart inbound):

12:08:36 [whatsapp] Inbound message <group>@g.us -> <primary> (group, 133 chars)
16:48:46 [whatsapp] Inbound message <number> -> <primary> (direct, image/jpeg, 243 chars)
18:06:25 [whatsapp] Inbound message <number> -> <primary> (direct, 60 chars)
20:40:58 [whatsapp] Inbound message <number> -> <primary> (direct, 77 chars)

No group inbound after 12:08 despite multiple messages sent to the group.

Expected Behavior

Group inbound messages should survive 408 WebSocket reconnect cycles, just as DM inbound now does after the 2026.4.12 fix.

Workaround

A scheduled daily gateway restart (e.g. midnight via LaunchAgent/cron) clears the degraded state. This prevents the accumulation of reconnect cycles that triggers the bug.

Notes

• The issue is specifically the group message subscription getting corrupted, not the entire inbound handler
• Dual-account setup may be a factor (both accounts reconnect on each 408 cycle)
• The 408 disconnects themselves are normal server-side keepalive timeouts — Baileys self-reconnects within seconds
• Previously tracked in WhatsApp: Persistent 408 session timeout loop — WebSocket keepalive not preventing server-side idle disconnect #63410 (keepAliveIntervalMs exposure request)