openclaw - 💡(How to fix) Fix Bug: Telegram polling TELEGRAM_POLL_RESTART_POLICY too aggressive — maxMs=30s causes restart storms

Summary

The TELEGRAM_POLL_RESTART_POLICY in dist/monitor-polling.runtime-*.js uses maxMs: 3e4 (30 seconds), which is too aggressive for network instability scenarios. During connectivity fluctuations, this causes rapid restart cycles that compound the problem rather than allowing graceful recovery.

Additionally:

• Stop timeout has no circuit breaker — consecutive stop timeouts trigger immediate retries without cooldown
• stopRunner/stopBot can be called repeatedly without deduplication, causing race conditions
• Watchdog-triggered stops bypass the unified stop entry point

Current Behavior (v2026.5.28)

const TELEGRAM_POLL_RESTART_POLICY = {
  initialMs: 2e3,  // 2s — too fast after a crash
  maxMs: 3e4,       // 30s — too short for network recovery
  factor: 1.8,
  jitter: .25
};

Suggested Fix

1. Harden restart policy: Increase initialMs to 3e4 and maxMs to 6e5 (10 minutes), with factor: 2 for proper exponential backoff:

const TELEGRAM_POLL_RESTART_POLICY = {
  initialMs: 3e4,  // 30s — give network time to stabilize
  maxMs: 6e5,       // 10 min — max wait before next attempt
  factor: 2,
  jitter: .2
};

1. Add stop-timeout circuit breaker: Track consecutive stop timeouts with burst counting; when threshold exceeded, apply exponential cooldown before next restart cycle.

2. Add requestStop() deduplication: Ensure stopRunner() and stopBot() are called at most once per polling cycle.

3. Add noteHealthyPollingCycle() tracking: Reset circuit breaker state after successful polling cycles.

Environment

• OpenClaw version: 2026.5.28 (67ddc1a)
• File: dist/monitor-polling.runtime-*.js
• Related: #57422, #57544, #56096

References

• Exponential backoff best practices: https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
• Circuit breaker pattern: https://learn.microsoft.com/azure/architecture/patterns/circuit-breaker