Problem: When Telegram API returns transient network errors (e.g., rate limits or temporary connectivity issues), OpenClaw's Telegram plugin retries every 3 seconds with ERROR-level logs, spamming the log file.

Observed behavior:

• Log entries every 3 seconds: telegram sendChatAction failed: Network request for 'sendChatAction' failed!
• During a 1-minute outage window, this generates 20+ ERROR entries
• ERROR level is misleading — the issue is transient network flakiness, not a system failure
• The gateway itself (RPC probe) remains healthy throughout

Expected behavior:

1. Exponential backoff on retry attempts (not fixed 3-second intervals)
2. Log at WARN level for transient failures, ERROR only after sustained failure (e.g., 5+ consecutive failures)
3. Circuit breaker that stops retrying after N failures and waits for a reset period
4. Suppress duplicate error messages (log once, then log summary after sustained failure)

Environment:

• OpenClaw CLI v2026.3.24
• macOS (Darwin 25.2.0)
• Node v25.8.2

Sample log entry (repeated every 3 seconds during outage):

{"subsystem":"telegram/api","1":"telegram sendChatAction failed: Network request for 'sendChatAction' failed!","_meta":{"runtime":"node","runtimeVersion":"25.8.2","hostname":"unknown","name":"{\"subsystem\":\"telegram/api\"}","parentNames":["openclaw"],"date":"2026-03-27T12:28:15.008Z","logLevelId":5,"logLevelName":"ERROR

Suggested approach:

• In the Telegram plugin's retry handler, implement:
  • minDelay = 3000, maxDelay = 60000, backoffMultiplier = 2
  • After 3 consecutive failures, escalate to WARN
  • After 10 consecutive failures, enter circuit breaker mode (stop retrying for 5 minutes)
  • Always log once at ERROR when transitioning to a new failure state