openclaw - 💡(How to fix) Fix Telegram polling stalls and gateway RPC times out during agent runs on Windows

Summary

On Windows 10 native, Telegram polling can receive inbound messages but then stop reacting/replying for minutes or until the operator restarts/resets the gateway/session. This has happened repeatedly during normal operation in Telegram topics.

The issue is broader than startup provider pre-warm: during inbound Telegram turns, the channel can appear configured/running/connected while gateway RPC, WebSocket handshakes, reactions, and agent session progress degrade or time out.

Environment

• OpenClaw 2026.5.22 (a374c3a)
• Windows 10 native, no WSL
• Gateway on loopback: 127.0.0.1:18789
• Telegram mode: polling
• Telegram group topics routed to dedicated agents
• Plugins enabled locally: codex, memory-core, telegram
• Agent model after local mitigation: codex/gpt-5.5 through Codex app-server
• Disabled locally to reduce load: cron, model pricing, native Telegram commands/native skills, shell env loading

Symptoms

• Telegram messages are received in the log, but the bot sometimes does not show a reaction and does not reply.
• openclaw channels status --deep --json may still show Telegram configured=true, running=true, connected=true.
• At the same time openclaw gateway health --json may time out.
• Browser/UI WebSocket connections may fail or close during the stall.
• Stalled sessions show active embedded agent runs without progress.
• Manual gateway restart and/or session archival/reset restores operation temporarily.

Evidence from logs

Token-bearing Telegram URLs were sanitized before reporting.

Startup/provider-related delays:

[telegram][default] channel exited: Bad Gateway | Telegram ingress worker exited with code 1
[telegram][default] starting provider (@clw27bot)
fetch timeout reached; aborting operation url=https://api.telegram.org/bot.../getMe
telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
[telegram][diag] isolated polling ingress started spool=...\telegram\ingress-spool-default
provider auth state pre-warmed in 303032ms eventLoopMax=209379.7ms

Inbound Telegram turn stalls:

Inbound message telegram:group:-1003946394862:topic:21 -> @clw27bot
liveness warning: reasons=event_loop_delay ... active=agent:tg-fnv-shared:telegram:group:-1003946394862:topic:21(processing/embedded_run,q=1,age=46s last=embedded_run:started)
telegram setMessageReaction failed: Network request for 'setMessageReaction' failed!
stalled session ... reason=active_work_without_progress classification=stalled_agent_run

Later repeated instance:

Inbound message telegram:group:-1003946394862:topic:21 -> @clw27bot
fetch timeout reached ... getMe
closed before connect ... handshake pending
handshake timeout
liveness warning: reasons=event_loop_delay,event_loop_utilization ... active=agent:tg-fnv-shared:telegram:group:-1003946394862:topic:21(processing/embedded_run,q=1,age=36s last=embedded_run:started)
gateway connect failed: Error: gateway closed (1000)
health cached ok after delay

One gateway health check during this state returned:

{
  "ok": false,
  "error": {
    "type": "gateway_transport_error",
    "kind": "timeout",
    "message": "gateway timeout after 10000ms",
    "timeoutMs": 10000
  }
}

Expected behavior

• Telegram ingress/polling should remain responsive enough to acknowledge or queue messages even when an agent run is slow.
• Telegram reactions should be best-effort and should not be affected by unrelated long-running gateway work where possible.
• Gateway health/RPC should remain responsive or expose a clear degraded state.
• Stalled Telegram sessions should recover or fail closed without requiring repeated manual gateway restarts.

Local mitigations tried

• Reduced enabled plugins to codex, memory-core, telegram.
• Disabled cron and reduced heartbeat load.
• Disabled model pricing checks.
• Disabled native Telegram commands/native skills.
• Changed all agents from ambiguous openai/gpt-5.5 routing to explicit codex/gpt-5.5.
• Archived/reset the saturated topic-21 session after compaction/provider errors.
• Added a lightweight local watchdog that restarts the gateway after repeated failed health/channel checks.

These mitigations improved some cases but do not address the underlying recurring Telegram stall pattern.

Questions

• Is isolated Telegram polling intended to stay responsive when the gateway event loop is degraded by provider auth, agent runs, compaction, or WebSocket handshakes?
• Can Telegram ingress/reaction handling be decoupled further from embedded agent execution?
• Should setMessageReaction failure be non-blocking and isolated from the main turn?
• Is there a supported configuration to bound event-loop starvation or auto-recover stalled_agent_run sessions?
• Are there additional diagnostics maintainers would like captured the next time this occurs?

Related

Related but narrower issue: #87976 focused on provider auth pre-warm blocking the gateway event loop. This report covers the repeated runtime Telegram stalls observed during normal topic use.