Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Split from #75687 (closed prematurely — only Bugs 1–2 were addressed on main). This is Bug 3 from that report.

On Windows with 8 Telegram bots, versions .24 and .25 exhibit Telegram polling stalls and sendMessage failures that make agents appear completely unresponsive.

What happens

After gateway boot, Telegram polling stalls are detected and force-restarted, but recovery fails and agents stop delivering messages:

[telegram] Polling stall detected (active getUpdates stuck for 138.99s); forcing restart.
[telegram] sendMessage failed: Network request for 'sendMessage' failed!

The gateway enters tight restart loops. The first message after boot may occasionally sneak through, then all subsequent messages are lost.

This is distinct from the startup fanout saturation fixed by CHANNEL_STARTUP_CONCURRENCY = 4 on main — the polling stalls occur after successful boot, during normal operation.

Environment

openclaw: v2026.4.24, v2026.4.25 (broken) — v2026.4.23 (working)
node: 22.21.1
os: Windows 11 Pro N (10.0.26200)
platform: win32
bots: 8 Telegram accounts
plugins: acpx, bonjour, browser, device-pair, file-transfer, memory-core, phone-control, talk-voice, telegram
launcher: Pinokio

Steps to reproduce

1. Windows 11, Node 22
2. Configure 8 Telegram bot accounts
3. Install openclaw v2026.4.24 or v2026.4.25
4. Start gateway, send messages to any bot
5. First message may get through; subsequent messages are lost
6. Logs show polling stall detection and sendMessage failures

Expected behavior

Telegram polling should remain stable after boot. Messages should be delivered reliably to all 8 bots.

Actual behavior

Polling stalls after 60–139s, forced restarts fail to recover, sendMessage calls fail with network errors. Agents appear completely unresponsive. Rolling back to .23 immediately restores functionality.

OpenClaw version

v2026.4.24, v2026.4.25

Operating system

Windows

Related issues

• Parent: Windows: Telegram unusable from .24 through .29 — event loop saturation, polling stalls, bonjour crash #75687 (closed — only startup fanout and Bonjour crash were fixed)
• Related: [Bug]: Gateway CPU pinned at 100%: root causes & workarounds (complements #75688) #75707 (broader event loop saturation — still open)