openclaw - 💡(How to fix) Fix Telegram channel can silently lose assistant replies after polling/transport stall [1 comments, 2 participants]

OpenClaw’s Telegram channel can enter a degraded state where inbound messages are accepted/queued, but outbound assistant replies fail with Telegram transport/network errors. The user experience is that the assistant appears to ignore messages.

Environment

• OpenClaw Gateway running as LaunchAgent on macOS
• Telegram direct-message channel enabled
• Gateway remained running and websocket probe was healthy
• No gateway restart was performed during the incident

Observed behavior

During a Telegram DM conversation, OpenClaw appeared to receive/route messages, but multiple visible replies did not reach Telegram.

Sanitized log timeline:

08:40:33 ERROR [telegram] Polling stall detected
  no completed getUpdates for 124.98s; forcing restart

08:40:48 ERROR [telegram] Polling runner stop timed out after 15s
08:40:48 ERROR Telegram polling runner stopped; restarting in 7.22s

08:40–08:42 ERROR telegram sendChatAction failed:
  Network request for 'sendChatAction' failed!

08:42:40 ERROR telegram sendMessage failed:
  Network request for 'sendMessage' failed!

08:42:40 ERROR telegram final reply failed:
  HttpError: Network request for 'sendMessage' failed!

08:42:41 ERROR telegram message processing failed:
  HttpError: Network request for 'sendMessage' failed!

08:45:01 INFO telegram sendMessage ok

08:45:17 ERROR telegram sendMessage failed:
  Network request for 'sendMessage' failed!

08:48:33 WARN liveness warning:
  active=agent:main:telegram:direct:<redacted>
  queued=agent:main:telegram:direct:<redacted>
  phase=channels.telegram.start-account

08:48:48 INFO telegram sendMessage ok
08:48:50 INFO telegram sendMessage ok

Impact

• User sent Telegram messages and saw no response.
• OpenClaw did not clearly notify the user/operator that delivery failed.
• The failure looked exactly like assistant non-responsiveness.
• Some runs appeared to remain queued/active while Telegram delivery was degraded.

Expected behavior

If Telegram delivery fails, OpenClaw should avoid silent loss. It should do one or more of:

1. Retry sendMessage with bounded backoff.
2. Preserve failed assistant replies for later resend.
3. Mark the Telegram channel/session as degraded.
4. Surface a visible delivery-failure event in the control/web session.
5. Avoid treating sendChatAction failures as normal/noisy background failures if they correlate with sendMessage failure.
6. Optionally fail over to another configured channel when available.

Suspected problem areas

• Telegram polling runner restart/rebuild after getUpdates stall.
• Shared Telegram transport/client state after polling stall.
• Outbound delivery error handling for final assistant replies.
• Session queue behavior when Telegram channel is degraded.
• Lack of operator-visible delivery-failure reporting.

Acceptance criteria

• A failed Telegram sendMessage does not silently disappear.
• The failed reply is either retried successfully or preserved with a clear failure state.
• The operator can see that Telegram delivery failed without digging through gateway logs.
• A polling stall/restart does not leave Telegram DM sessions queued indefinitely.
• Logs include enough correlation between inbound message/run ID and outbound delivery failure to debug the incident.