Problem

When the WhatsApp gateway briefly disconnects (status 499, 428, 408 — typically reconnects within 5-10 seconds), any outbound messages generated by the agent during that window are silently lost. The session transcript records the response as generated, but it never reaches WhatsApp. No error is surfaced to the agent or the user.

Real-world impact

Today (2026-03-01), the gateway disconnected at 22:52:27 and reconnected at 22:52:38 (11 seconds). During that window, a response to a voice message in a WhatsApp group was generated and "sent" — but never delivered. The user had to ask why the agent didn't respond, and the agent had to manually diagnose and resend. This erodes trust, especially in group chats where other participants (e.g. elderly family members) expect responses.

Observed disconnect frequency

Four WhatsApp disconnects in a single day (status codes 499, 428, 408), each lasting 5-11 seconds. These are brief but frequent enough that message loss is a recurring issue.

Proposed solution

An outbound message queue that:

1. Detects send failure — when the WhatsApp provider returns an error or the connection is unavailable
2. Persists the unsent message — to a local queue (e.g. pending-messages.json or SQLite)
3. Drains on reconnect — automatically resends queued messages once the gateway reconnects
4. Surfaces failures — if a queued message still fails after N retries, notify the agent/session so it can take action

Additional considerations

• Queue should respect message ordering (FIFO per chat/group)
• Should handle media attachments (filePath, buffer) not just text
• TTL on queued messages (don't send a stale response hours later)
• Config option to enable/disable and set retry limits

Current workaround

Manual detection via log auditing and resending through the message tool. Not scalable.

Environment

• OpenClaw version: 2026.2.26
• WhatsApp provider: built-in (Baileys)
• Gateway mode: local