openclaw - 💡(How to fix) Fix Telegram polling runner deadlock after network instability — no watchdog for kill+respawn

Summary

After a network instability event with api.telegram.org, the Telegram polling runner entered a terminal deadlock state. Once the network recovered, the runner did not self-recover — it remained stuck, dropping all incoming messages until a manual gateway restart was performed.

Observed behavior

• Network instability window: ~16:40–19:38 BRT (2026-05-26)
• Telegram stopped responding to all OpenClaw messages during this window
• After network recovery, the runner remained in deadlock indefinitely
• Recovery required a full manual gateway restart

Root cause

The polling runner has no watchdog mechanism to detect a terminal deadlock and force a kill + respawn. When api.telegram.org becomes unreachable temporarily, the runner can enter a stuck state from which it cannot recover on its own.

Expected behavior

A watchdog should:

1. Detect deadlock / unresponsiveness (e.g., no heartbeat from the runner for N seconds after network is stable)
2. Force kill the stuck runner
3. Respawn it automatically — without requiring a full gateway restart
4. Log/alert the event so operators are notified

Impact

• All agents linked to the Telegram channel become inaccessible during deadlock
• No self-healing — requires manual operator intervention to restore service

Environment

• OpenClaw gateway (self-hosted VPS)
• Telegram provider / polling mode
• Network: brief instability with api.telegram.org triggered the condition

Suggested fix

Implement a supervisor/watchdog for the Telegram polling runner that monitors runner liveness (e.g., last successful poll timestamp) and automatically kills + respawns on deadlock detection after a configurable timeout.

This is a known technical debt — logging here for tracking and future prioritization.