Summary

In OpenClaw 2026.6.1, Telegram direct-message delivery can become unreliable after Telegram API network timeouts. A direct-message lane may remain guarded after a failed/aborted send path, causing later DM messages to be delayed or not reflected in the target agent session until recovery.

Environment

• OpenClaw version: 2026.6.1
• Channel: Telegram
• Telegram mode: polling
• Affected route: direct DM to an agent session
• Gateway bind: lan

Observed behavior

During a Telegram network failure window, the user sent multiple direct messages. Some inbound Telegram updates were visible in gateway logs, but the corresponding agent session did not process/respond to the messages promptly. The agent appeared unresponsive until the lane recovered and later messages created/updated a fresh session.

Relevant sanitized log patterns:

telegram sendMessage failed: Network request for 'sendMessage' failed!
telegram sendChatAction failed: Network request for 'sendChatAction' failed!
fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (... request-timeout ...)
[telegram][diag] timed out spooled update <update_id> did not stop within 5s after reply abort; keeping lane telegram:<user_id> guarded.
Delivery entry <id> delivery state is send_attempt_started; refusing blind replay without adapter reconciliation
Telegram reconnect drain: retry failed ... delivery state is send_attempt_started; refusing blind replay without adapter reconciliation

There were also diagnostic stale/stalled session messages around the same time, but the user-visible failure was that direct messages appeared to be ignored or delayed.

Expected behavior

Telegram inbound updates should be durable and should not be blocked by outbound delivery failures such as sendChatAction or sendMessage timeouts.

A Telegram network timeout should at worst delay outbound delivery. It should not silently prevent later direct messages from reaching the agent session.

Why this matters

From the user's perspective, the assistant appears to stop replying even though messages were sent. This is particularly confusing because later messages may start working again, making the issue look intermittent.

Suggested fixes

1. Make sendChatAction best-effort only. Failure should not affect inbound update processing or lane health.
2. Persist inbound Telegram updates before outbound delivery/transcription/agent side effects.
3. Add a bounded TTL/auto-release for guarded Telegram lanes.
4. Reconcile send_attempt_started delivery state after reconnect instead of refusing blind replay indefinitely.
5. Emit a visible diagnostic/system event when a DM lane is guarded due to Telegram delivery failure.

Reproduction idea

1. Run OpenClaw with Telegram polling enabled.
2. Open a Telegram DM to an agent.
3. Send multiple quick DM messages.
4. While a reply/sendChatAction is in progress, induce Telegram API timeouts, for example by blocking or delaying api.telegram.org traffic.
5. Observe whether the DM lane enters guarded state and whether subsequent inbound messages are delayed/missing from the agent session.