Description

When a subagent (e.g. Finance) completes its task and returns results to the main agent, the completion announcement times out repeatedly, causing the main agent to send the same response to the user 2 times.

Environment

• OpenClaw: 2026.3.8
• OS: Linux 6.8.0-104-generic (x64)
• Node: 22.22.0
• Channel: Telegram

Steps to Reproduce

1. User sends a message that triggers delegation to a subagent (e.g. "สมัคร canva 29 บาท" → Finance agent)
2. Main agent delegates to subagent via sessions_spawn
3. Subagent completes the task successfully
4. Subagent announce completion times out (gateway timeout after 60000ms)
5. Retry mechanism retries up to 4 times, each timing out
6. Main agent sends the result to user TWICE (~30s apart)

Logs

22:16:34 [ws] ⇄ res ✓ agent.wait 62230ms — first result delivered OK
22:17:34 [warn] Subagent announce completion direct announce agent call transient failure, retrying 2/4 in 5s: gateway timeout after 60000ms
22:18:39 [warn] retrying 3/4 in 10s: gateway timeout after 60000ms
22:19:49 [warn] retrying 4/4 in 20s: gateway timeout after 60000ms
22:20:18 — DUPLICATE message sent to user (same content as 22:16:34)
22:21:09 Subagent completion direct announce failed for run xxx: gateway timeout after 60000ms

Second instance (same session, different transaction):

22:22:19 [jarvis-v2] sessions_spawn → finance
22:23:39 [ws] ⇄ res ✓ agent.wait 79394ms — result delivered
22:24:09 — DUPLICATE message (identical content, 30s later)

Expected Behavior

• Subagent completion should be announced once
• If announce times out, the result should not be re-delivered to the user
• Idempotency: even if retries happen internally, the user-facing message should be deduplicated

Actual Behavior

• Announce completion retries cause the main agent to receive/process the result multiple times
• Each receipt triggers a new message to the user → duplicate messages on Telegram

Additional Context

• This happens consistently, not intermittently
• The gateway is running on ws://127.0.0.1:18789 (local loopback) so network latency should not be a factor
• subagents.maxConcurrent is set to 8
• The 60s gateway timeout seems too short for agent.wait calls which regularly take 60-80s
• This is a gateway-level issue, not model-specific — the duplicate delivery happens regardless of which model is used