openclaw - 💡(How to fix) Fix [Bug]: 2026.5.12 Telegram healthMonitor false-positive on idle accounts triggers exit code 1 loop

Environment

Summary

After upgrading from 2026.5.3-1 → 2026.5.12 (npm update + doctor --fix automatic migration), Telegram bot accounts with no incoming traffic enter an infinite restart loop. The healthMonitor declares idle workers as disconnected and triggers worker.terminate() → exit code 1 → auto-restart in 5s → cycle repeats every 3-6 minutes.

Accounts that receive messages (i.e., active conversation) don't loop because lastEventAt updates and satisfies the watchdog.

Symptoms (from /tmp/openclaw/openclaw-*.log)

[telegram:<account>] health-monitor: restarting (reason: disconnected)
[<account>] channel stop exceeded 5000ms after abort; continuing shutdown
[<account>] channel exited: Telegram ingress worker exited with code 1
[<account>] auto-restart attempt 1/10 in 5s
[<account>] starting provider (@<botname>)
[telegram][diag] isolated polling ingress started
# loop repeats every 3-6 min

Quantitative evidence

In a 7h window (07:37 → 14:34 BRT) before workaround:

• Total exit code 1 events: 63
• Distribution: bot with traffic = 11 exits; idle bots = 21 + 31 exits
• 0 exit code 1 in the same machine on day before upgrade (2026-05-16.log)
• Bug appeared immediately after doctor --fix ran at 07:30:45 (postinstall)

Root cause (analyzed from source)

The healthMonitor expects "completed getUpdates liveness" (i.e., non-empty array of updates) within pollingStallThresholdMs (default 120s, cap 600s). Idle accounts return HTTP 200 + empty array from Telegram — which is normal long-poll behavior but is treated as no liveness. After pollingStallThresholdMs, the worker is killed.

Steps to reproduce

1. Configure OpenClaw 2026.5.12 with at least 2 Telegram bot accounts
2. Set traffic only to one account (leave others idle)
3. Wait 2-10 min
4. Observe idle workers in restart loop in the log

Expected behavior

HTTP 200 + empty getUpdates array should be treated as liveness OK (Telegram responded normally, just no new updates). Only actual transport errors (HTTP error, timeout, 4xx/5xx) should trigger health-monitor restart.

Workaround (currently applied)

Set healthMonitor.enabled: false per-account:

"channels": {"telegram": {"accounts": {
  "default": {"healthMonitor": {"enabled": false}},
  "judite": {"healthMonitor": {"enabled": false}},
  "tesla": {"healthMonitor": {"enabled": false}}
}}}

Side effect: real disconnections (token revoked, network issues) no longer trigger restart automatically.

Suggested fix

Distinguish in healthMonitor logic between:

• HTTP error / timeout / 4xx-5xx → disconnect, restart
• HTTP 200 + empty getUpdates array → alive, don't restart

Alternative: add config healthMonitor.requireUpdatesForLiveness: false (default true for back-compat).

Related

• This bug is in the channels.telegram.healthMonitor path, distinct from #75852 (409 Conflict polling) and #82989 (codex app-server turn/started stall).
• Other healthMonitor false-positive issues for Discord: #40073 (closed 2026-04-27) — similar class of bug.

Additional context

This was the first of 4 encountered bugs in 2026.5.12 (cron watchdog #81368, codex app-server #82989, and a schema divergence) — all stem from doctor --fix automatic migration on upgrade. Full incident analysis available locally.