Telegram delivery reliability: polling stalls can lead to silent outbound message loss

Summary

On OpenClaw 2026.3.12, Telegram Bot API connectivity may remain generally healthy while the gateway's Telegram polling loop intermittently stalls/restarts. During those recovery windows, outbound sendMessage delivery can fail and the effective recovery path is not strong enough at runtime, leading to silent or operator-visible message loss.

This appears to be a gap between:

• polling restart/recovery behavior, and
• outbound delivery recovery behavior for non-idempotent Telegram sends.

Observed behavior

In production use, logs repeatedly showed patterns like:

• Polling stall detected
• sendChatAction failed
• sendMessage failed: Network request for 'sendMessage' failed!
• polling runner stop/restart cycles

At the same time:

• direct short HTTPS/Bot API probes to api.telegram.org succeeded,
• DNS and IPv4 routing looked healthy,
• the failure pattern was intermittent rather than a full Telegram outage.

This suggests the issue is not simply "Telegram unreachable", but rather that the long-poll / recovery path can degrade and outbound delivery is not fully protected when that happens.

Why this is harmful

A message can be prepared by the assistant but still fail to reach Telegram during a polling/recovery disruption.
From the operator perspective, this looks like silent message loss or partial reply loss.

Suspected design gap

There is already a disk-backed outbound delivery queue and startup recovery, but runtime delivery recovery appears insufficient for this failure mode.

The practical gap seems to be:

1. polling stalls or restarts,
2. outbound Telegram send fails during that window,
3. recovery is not strong enough as a continuous runtime mechanism,
4. result: delivery may be stuck, dropped, or ambiguous from the operator perspective.

Proposed direction

A robust fix would combine:

1. Runtime outbound delivery recovery worker

   • periodically scan pending deliveries
   • retry only safe-to-retry entries
   • run without requiring gateway restart
   • trigger an immediate recovery pass after Telegram polling restart/recovery

2. Delivery failure classification

   • safe_to_retry
   • ambiguous
   • permanent

3. Stateful delivery entries

   • pending
   • retryable
   • ambiguous
   • delivered
   • failed

This would reduce silent message loss while avoiding blind retries for ambiguous non-idempotent send outcomes.

Expected behavior

When Telegram polling experiences a transient stall/restart:

• outbound deliveries should not be silently lost,
• safe transient failures should be retried automatically,
• ambiguous failures should be preserved/held rather than blindly retried,
• gateway restart should not be required to recover eligible deliveries.

Version notes

• Reproduced on: 2026.3.12
• A local comparison against 2026.3.13 did not reveal an obvious upstream runtime recovery worker / failure-classification / stateful-outbox implementation for this specific Telegram delivery gap.

Optional note

A local prototype patch implementing the runtime worker + failure classes + stateful delivery entries significantly improves the recovery model, if maintainers want a more concrete direction for upstreaming.