Bug type

Regression (worked before, now fails) — observed on 2026.5.x

Beta release blocker

No (operational impact: false-negative dispatch status causes humans/agents to retry already-delivered messages or treat them as failed)

Summary

wa-send.py (send-gate CLI wrapper for WhatsApp dispatch) returns DISPATCHED-UNKNOWN with GatewayTransportError: gateway timeout after 10000ms while the underlying WhatsApp send actually succeeds and the message is delivered to the recipient.

The 10s ack timeout on the dispatch RPC (ws://127.0.0.1:18789) is too short when the WhatsApp channel is mid-reconnect or stuck in channels.whatsapp.start-account. The gateway eventually flushes the send to Baileys; recipients receive the message; but the CLI has already returned unknown. The send-gate lock file is left at outcome=unknown, downstream agents/scripts believe the send failed, and operators are tempted to retry — risking duplicate sends.

Steps to reproduce

1. OpenClaw 2026.5.x, macOS arm64, single host, gateway transport ws://127.0.0.1:18789.
2. WhatsApp channel under load: gateway err log shows recurring [whatsapp] Web connection closed (status 428). Retry 1/12 in 2.x s… (status=428 Precondition Required Connection Terminated) every ~5 min and at least one liveness warning of the form phase=channels.whatsapp.start-account recentPhases=channels.whatsapp.start-account:NNNms with NNN > 10000 (in our incident: ~12,669,716ms — channel hung in start-account for ~3.5h).
3. Send a WhatsApp message via the send-gate CLI (wa-send.py --target "+<E.164>" --message "…") during this window.
4. CLI returns within ~10s with DISPATCHED-UNKNOWN: target=… key=… reason=unknown cli=GatewayTransportError: gateway timeout after 10000ms and exit code 1.
5. ~5–10 minutes later (after the WA channel finishes reconnecting), the recipient confirms the message arrived exactly once.

Evidence (real incident, 2026-05-10)

Send-gate lock (recipient details redacted):

{"attempts": 1, "channel": "whatsapp", "dispatcher_exit": 1,
 "first_attempt_ts": 1778400461.37, "key": "<REDACTED>",
 "outcome": "unknown", "target_canonical": "+<RECIPIENT>"}

Gateway err log around incident:

• 2026-05-10T11:07:19 [diagnostic] liveness warning: reasons=event_loop_delay … phase=channels.whatsapp.start-account recentPhases=channels.whatsapp.start-account:12669716ms … work=[active=agent:…(processing/model_call,q=1,age=6s)]
• 2026-05-10T11:08:06 [whatsapp] Web connection closed (status 428). Retry 1/12 in 2.22s…
• Same 428 reconnect line repeats every ~5 min for days (visible across multiple days in 2026-05).

CLI return: DISPATCHED-UNKNOWN … cli=GatewayTransportError: gateway timeout after 10000ms.

Recipient confirmation (out-of-band): the WhatsApp message arrived exactly once, ~7 min after the CLI returned unknown.

Follow-up test send to a different recipient 6 min later: reason=dispatched returned in <1s — transport itself is healthy, only ack delivery during the start-account stall is broken.

Expected

Either:

• (a) the dispatch RPC should not return unknown when the underlying send is actually queued and will be flushed when the WA channel reconnects — the send-gate lock should be reconciled to dispatched once a Baileys Message ID is observed; or
• (b) the dispatch ack timeout should be tunable / longer when the WA channel is in start-account (back-pressure aware), so the CLI does not return false-negative unknown outcomes for sends that actually succeed.

Actual

CLI returns unknown after exactly 10000ms while the send succeeds asynchronously. Send-gate lock is permanently outcome=unknown with no reconciliation path. Operators / agents must verify delivery out-of-band (asking the recipient) to know whether retrying is safe.

Related issues

• [Bug]: Sub-agent announce-back fails with 10-second gateway WS timeouts; parent agents never receive child output, causing chat sessions to appear non-responsive #79032 — same 10s gateway WS timeout pattern on a different RPC (sub-agent announce-back). Likely the same ws://127.0.0.1:18789 RPC client wrapping every gateway call with a hard-coded 10000ms deadline.
• WhatsApp channel stuck in start-account phase after restart — inbound messages silently dropped #78690 — WhatsApp channel stuck in start-account phase after restart (upstream condition that exposes the ack-timeout false-negative).
• [Bug]: channels.whatsapp.start-account blocks event loop ~40s, triggering reconnect storm #78165 — channels.whatsapp.start-account blocks event loop, triggering reconnect storm.
• [Bug]: gateway/channels/whatsapp ⁠ — channel exited with HTTP 428 Precondition Required #75736 — WhatsApp 428 Precondition Required reconnect loop.

Suggested fix directions

1. Make the gateway WS dispatch ack timeout configurable (default >10s) or back-pressure aware when the destination channel is in a known restart phase.
2. After a dispatched-unknown outcome, reconcile send-gate locks once a Baileys Message ID is observed for the same (target, content_hash) within N minutes — flip outcome from unknown → dispatched and emit a follow-up CLI/heartbeat event so callers can stop treating the send as failed.
3. Differentiate "queued for delivery" vs "ack received" in the CLI return code so wa-send.py can return QUEUED (exit 2) instead of DISPATCHED-UNKNOWN (exit 1) when the underlying queue accepted the send but the channel is mid-reconnect.

Environment

• OpenClaw 2026.5.x, macOS 25.4.0 arm64, node 25.9.0
• WhatsApp plugin (Baileys-based), default account
• Gateway transport: ws://127.0.0.1:18789 (loopback)