Bug type
Regression (still present in 4.29)
Summary
Telegram polling stalls and web_fetch timeouts persist on Windows after upgrading to 4.29. Both #66885 and #59198 are closed but the underlying issue is not fixed. Rolled back to 4.23. Two config-level mitigations were found that improve stability but do not fully resolve the problem.
Environment
- OS: Windows 10 (10.0.26200) x64
- Node.js: v24.14.1
- OpenClaw: 2026.4.29 (tested), stable on 2026.4.23
- Channel: Telegram long-polling, 5 bot accounts
Steps to reproduce
- Run OpenClaw 4.29 on Windows with 5 Telegram bot accounts configured
- Start gateway — Telegram polling stalls and web_fetch requests timeout within minutes
- Roll back to 4.23 — issue disappears
Mitigations found (partial fixes, applied on 4.23)
channels.telegram.network.autoSelectFamily: false — stops undici IPv6→IPv4 fallback that causes duplicate getUpdates requestschannels.telegram.accounts.default.enabled: false — disables phantom default account that inherits another bot's token and creates a rogue polling loop
These two config changes significantly improve stability on 4.23 with 5 bots. However they did not prevent the stall/timeout symptoms on 4.29.
Root cause (from #66885)
The allowH2: false fix applied to the web_fetch/web_search dispatchers in 4.7 was never applied to the Telegram polling dispatcher. On Windows with non-routable IPv6, undici attempts HTTP/2 and blocks the event loop. This is still present in 4.29.
Workaround
NODE_OPTIONS=--dns-result-order=ipv4first in env.vars (forces IPv4 DNS) combined with the two config changes above provides partial relief on 4.23 but is not sufficient on 4.29.
Request
Apply allowH2: false to the Telegram polling dispatcher, consistent with the fix already applied to web_fetch in 4.7. Also consider isolating the per-bot undici connection pools to prevent getUpdates cross-contamination (#59198).
Bug type
Regression (still present in 4.29)
Summary
Telegram polling stalls and web_fetch timeouts persist on Windows after upgrading to 4.29. Both #66885 and #59198 are closed but the underlying issue is not fixed. Rolled back to 4.23. Two config-level mitigations were found that improve stability but do not fully resolve the problem.
Environment
Steps to reproduce
Mitigations found (partial fixes, applied on 4.23)
channels.telegram.network.autoSelectFamily: false— stops undici IPv6→IPv4 fallback that causes duplicate getUpdates requestschannels.telegram.accounts.default.enabled: false— disables phantom default account that inherits another bot's token and creates a rogue polling loopThese two config changes significantly improve stability on 4.23 with 5 bots. However they did not prevent the stall/timeout symptoms on 4.29.
Root cause (from #66885)
The
allowH2: falsefix applied to the web_fetch/web_search dispatchers in 4.7 was never applied to the Telegram polling dispatcher. On Windows with non-routable IPv6, undici attempts HTTP/2 and blocks the event loop. This is still present in 4.29.Workaround
NODE_OPTIONS=--dns-result-order=ipv4firstin env.vars (forces IPv4 DNS) combined with the two config changes above provides partial relief on 4.23 but is not sufficient on 4.29.Request
Apply
allowH2: falseto the Telegram polling dispatcher, consistent with the fix already applied to web_fetch in 4.7. Also consider isolating the per-bot undici connection pools to prevent getUpdates cross-contamination (#59198).