Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
Telegram polling stalls every 10-12 minutes on Windows with UND_ERR_SOCKET / event loop freeze; subagent announce also times out during subagent runs. Both issues started after upgrading from 2026.4.1 to 2026.4.12. Root cause identified as undici attempting HTTP/2 + IPv6 on Windows — the allowH2: false fix applied to web_fetch in 4.7 was not applied to the Telegram polling dispatcher.
Steps to reproduce
I. Run OpenClaw 2026.4.12 on Windows with IPv6 present but not routable to api.telegram.org
II. Start the gateway and observe fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_SOCKET) appearing in logs every 10-12 minutes.
III. During each fallback event, observe node.list response times of 90-200 seconds — gateway event loop completely frozen.
IV. Spawn a subagent during or near a freeze — observe subagent announce timeout with gateway timeout after 10000ms.
V. Confirmed: curl -6 --max-time 10 https://api.telegram.org/ times out; curl -4 succeeds
Expected behavior
Telegram polling should work reliably on Windows regardless of IPv6 reachability. On 2026.4.1 the gateway booted fast and agent responded within seconds. The allowH2: false fix applied to web_fetch/web_search dispatchers in 4.7 should also be applied to the Telegram polling dispatcher to prevent undici from attempting HTTP/2 + IPv6 and blocking the event loop on failure.
Actual behavior
On 2026.4.12, the Telegram polling dispatcher attempts HTTP/2 + IPv6 via undici, which hangs silently on Windows when IPv6 is not routable. This blocks the Node.js event loop for 90-200 seconds every 10-12 minutes. During each freeze: all WebSocket responses stall, Telegram messages are not received or sent, subagent announce calls timeout, and the polling stall detector itself is delayed because the watchdog timer cannot fire while the event loop is blocked. Disabling IPv6 at the Windows adapter level reduced freeze frequency but did not eliminate it — undici still attempts IPv6 internally. Rolling back to 2026.4.1 eliminated the issue entirely. The regression correlates with the undici 8.0 HTTP/2 change introduced in 4.7 where allowH2: false was applied to web_fetch/web_search but not to the Telegram polling dispatcher.
OpenClaw version
2026.4.12 (1c0672b)
Operating system
Windows Server 2022 (Proxmox VM)
Install method
npm global
Model
anthropic/claude-haiku-4-5-20251001
Provider / routing chain
openclaw -> anthropic (primary) -> google (suspended) -> cerebras -> groq -> sambanova (fallback)
Additional provider/model setup details
Primary model is anthropic/claude-haiku-4-5-20251001. Google API key suspended — all 3 Gemini fallbacks fail with CONSUMER_SUSPENDED. Cerebras returns 400. Groq exceeds TPM limit (48k requested, 12k limit). Sambanova works as last resort. Issue is not model-related — polling stalls occur even when gateway is idle with no active agent runs. Confirmed working on 2026.4.1 with identical model config.
Logs, screenshots, and evidence
[telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_SOCKET)
[ws] ⇄ res ✓ node.list 194900ms
[telegram] Polling stall detected (active getUpdates stuck for 199.95s); forcing restart.
Subagent announce failed: Error: gateway timeout after 10000ms
Impact and severity
Affected: Any Windows user running OpenClaw 2026.4.12+ with IPv6 present but not routable to api.telegram.org (common on VPS/VM environments).
Severity: Blocks workflow — Telegram is the primary interface for agent interaction. Messages are delayed 2-12 minutes per polling stall cycle, subagents cannot report results back to the parent agent, and cron job results are silently lost.
Frequency: Always reproducible — polling stalls every 10-12 minutes without interruption for the entire gateway session.
Consequence: Agent is effectively unreliable as a primary assistant — users cannot depend on timely responses, subagent tasks complete silently with no feedback, and multi-step workflows requiring subagent coordination fail consistently.
Additional information
Last known good version: 2026.4.1 — gateway booted in ~70 seconds, Telegram responses within seconds, no polling stalls observed. First known bad version: 2026.4.12 (not bisected between 4.1 and 4.12 — versions 4.5, 4.7, 4.8 attempted but had missing dependencies on Windows). Workarounds attempted: disabling IPv6 at Windows adapter level reduced freeze frequency but did not eliminate it. Setting streamMode: off and autoSelectFamily: false in openclaw.json had no effect. Node.js version: 24.14.1. The subagent-registry.runtime.js file is also missing from the 4.12 npm package — causes best-effort cleanup errors on every subagent run (ERR_MODULE_NOT_FOUND), though this appears to be a separate packaging issue.
Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
Telegram polling stalls every 10-12 minutes on Windows with UND_ERR_SOCKET / event loop freeze; subagent announce also times out during subagent runs. Both issues started after upgrading from 2026.4.1 to 2026.4.12. Root cause identified as undici attempting HTTP/2 + IPv6 on Windows — the allowH2: false fix applied to web_fetch in 4.7 was not applied to the Telegram polling dispatcher.
Steps to reproduce
I. Run OpenClaw 2026.4.12 on Windows with IPv6 present but not routable to api.telegram.org
II. Start the gateway and observe fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_SOCKET) appearing in logs every 10-12 minutes.
III. During each fallback event, observe node.list response times of 90-200 seconds — gateway event loop completely frozen.
IV. Spawn a subagent during or near a freeze — observe subagent announce timeout with gateway timeout after 10000ms.
V. Confirmed: curl -6 --max-time 10 https://api.telegram.org/ times out; curl -4 succeeds
Expected behavior
Telegram polling should work reliably on Windows regardless of IPv6 reachability. On 2026.4.1 the gateway booted fast and agent responded within seconds. The allowH2: false fix applied to web_fetch/web_search dispatchers in 4.7 should also be applied to the Telegram polling dispatcher to prevent undici from attempting HTTP/2 + IPv6 and blocking the event loop on failure.
Actual behavior
On 2026.4.12, the Telegram polling dispatcher attempts HTTP/2 + IPv6 via undici, which hangs silently on Windows when IPv6 is not routable. This blocks the Node.js event loop for 90-200 seconds every 10-12 minutes. During each freeze: all WebSocket responses stall, Telegram messages are not received or sent, subagent announce calls timeout, and the polling stall detector itself is delayed because the watchdog timer cannot fire while the event loop is blocked. Disabling IPv6 at the Windows adapter level reduced freeze frequency but did not eliminate it — undici still attempts IPv6 internally. Rolling back to 2026.4.1 eliminated the issue entirely. The regression correlates with the undici 8.0 HTTP/2 change introduced in 4.7 where allowH2: false was applied to web_fetch/web_search but not to the Telegram polling dispatcher.
OpenClaw version
2026.4.12 (1c0672b)
Operating system
Windows Server 2022 (Proxmox VM)
Install method
npm global
Model
anthropic/claude-haiku-4-5-20251001
Provider / routing chain
openclaw -> anthropic (primary) -> google (suspended) -> cerebras -> groq -> sambanova (fallback)
Additional provider/model setup details
Primary model is anthropic/claude-haiku-4-5-20251001. Google API key suspended — all 3 Gemini fallbacks fail with CONSUMER_SUSPENDED. Cerebras returns 400. Groq exceeds TPM limit (48k requested, 12k limit). Sambanova works as last resort. Issue is not model-related — polling stalls occur even when gateway is idle with no active agent runs. Confirmed working on 2026.4.1 with identical model config.
Logs, screenshots, and evidence
Impact and severity
Affected: Any Windows user running OpenClaw 2026.4.12+ with IPv6 present but not routable to api.telegram.org (common on VPS/VM environments).
Severity: Blocks workflow — Telegram is the primary interface for agent interaction. Messages are delayed 2-12 minutes per polling stall cycle, subagents cannot report results back to the parent agent, and cron job results are silently lost.
Frequency: Always reproducible — polling stalls every 10-12 minutes without interruption for the entire gateway session.
Consequence: Agent is effectively unreliable as a primary assistant — users cannot depend on timely responses, subagent tasks complete silently with no feedback, and multi-step workflows requiring subagent coordination fail consistently.
Additional information
Last known good version: 2026.4.1 — gateway booted in ~70 seconds, Telegram responses within seconds, no polling stalls observed. First known bad version: 2026.4.12 (not bisected between 4.1 and 4.12 — versions 4.5, 4.7, 4.8 attempted but had missing dependencies on Windows). Workarounds attempted: disabling IPv6 at Windows adapter level reduced freeze frequency but did not eliminate it. Setting streamMode: off and autoSelectFamily: false in openclaw.json had no effect. Node.js version: 24.14.1. The subagent-registry.runtime.js file is also missing from the 4.12 npm package — causes best-effort cleanup errors on every subagent run (ERR_MODULE_NOT_FOUND), though this appears to be a separate packaging issue.