Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Telegram polling stall + subagent announce timeout on Windows (4.12) — undici HTTP/2 root cause [2 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#66885•Fetched 2026-04-16 06:37:25
View on GitHub
Comments
2
Participants
3
Timeline
6
Reactions
0
Author
swissfoneswissfone
Participants
Magicray1217Magicray1217neeravmakwananeeravmakwanaswissfoneswissfone
Timeline (top)
commented ×2cross-referenced ×2labeled ×2

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.

Error Message

[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

Root Cause

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.

Fix Action

Fix / Workaround

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.

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

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.

PR fix notes

PR #66889: Telegram: disable HTTP/2 polling transport

Description (problem / solution / changelog)

Summary

  • Problem: Telegram polling still built raw undici dispatchers on the transport path, so the repo's HTTP/1.1 guard never reached getUpdates.
  • Why it matters: On affected Windows installs, long polling could stall for minutes, freeze Telegram delivery, and time out subagent announce.
  • What changed: route Telegram transport dispatcher creation through the shared HTTP/1.1 helpers and extend the Telegram transport tests to lock in allowH2: false for direct, env-proxy, and explicit-proxy paths.
  • What did NOT change (scope boundary): this does not change polling retry policy, stall watchdog behavior, or Telegram session restart heuristics.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #66885
  • Related #
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: extensions/telegram/src/fetch.ts instantiated raw undici Agent / EnvHttpProxyAgent / ProxyAgent dispatchers instead of the shared HTTP/1.1-only helper path, so Telegram polling still allowed undici 8 HTTP/2 ALPN on the affected transport path.
  • Missing detection / guardrail: the Telegram fetch transport tests covered fallback and retry behavior, but they did not assert the allowH2: false invariant on the constructed dispatchers.
  • Contributing context (if known): the shared HTTP/1.1 guard already existed in src/infra/net/undici-runtime.ts and was already used by other guarded transport paths.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: extensions/telegram/src/fetch.test.ts
  • Scenario the test should lock in: direct, env-proxy, and explicit-proxy Telegram dispatchers all set allowH2: false while keeping the existing sticky IPv4 fallback behavior.
  • Why this is the smallest reliable guardrail: the regression lives in Telegram dispatcher construction, so this is the narrowest place that can prove the fix without needing a Windows-only repro lane.
  • Existing test that already covers this (if any): the existing Telegram fetch transport suite already covered fallback and retry behavior; this PR extends that suite to cover the missing HTTP/1.1 invariant.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

  • Telegram polling now uses HTTP/1.1-only undici dispatchers on the transport path, matching the repo's guarded transport behavior.
  • Windows installs affected by the HTTP/2/IPv6 stall should stop freezing long-polling delivery and the related subagent announce timeouts.

Diagram (if applicable)

N/A

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS 15.3 dev host; issue repro/evidence from the linked Windows report
  • Runtime/container: local repo build
  • Model/provider: N/A
  • Integration/channel (if any): Telegram
  • Relevant config (redacted): Telegram polling with the default Bot API host

Steps

  1. Construct Telegram transport for direct, env-proxy, or explicit-proxy polling paths.
  2. Inspect the dispatcher options used for Telegram API requests.
  3. Confirm those dispatchers keep allowH2: false while preserving the existing sticky IPv4 fallback behavior.

Expected

  • Telegram polling transport disables HTTP/2 on its dispatchers and preserves current fallback logic.

Actual

  • Before this PR, Telegram built raw undici dispatchers on this path, so the HTTP/1.1 guard was missing.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios: traced the polling path from polling-session -> bot -> fetch, confirmed Telegram now builds dispatchers through the shared HTTP/1.1 helpers, and ran pnpm test extensions/telegram/src/fetch.test.ts, pnpm plugin-sdk:api:check, and pnpm build.
  • Edge cases checked: direct transport, env-proxy transport, explicit proxy transport, sticky IPv4 fallback, pinned IP fallback, and plugin-sdk export validation.
  • What you did not verify: a live Windows VM repro against Telegram.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk: widening the plugin-sdk runtime surface by three helpers.
    • Mitigation: kept the change additive on the existing fetch-runtime subpath and verified it with pnpm plugin-sdk:api:check plus pnpm build.
  • Risk: there may be Windows-specific behavior outside dispatcher construction that this PR does not cover.
    • Mitigation: kept the fix scoped to the verified root cause and preserved the existing Telegram fallback/restart behavior.

Additional Notes

  • AI-assisted: Yes
  • Testing degree: targeted regression tests + build
  • Prompt/session logs: not included
  • Confirmed understanding of the changed code path: Yes

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/telegram/src/fetch.test.ts (modified, +19/-0)
  • extensions/telegram/src/fetch.ts (modified, +7/-4)
  • src/plugin-sdk/fetch-runtime.ts (modified, +5/-0)

PR #67083: fix(telegram): apply allowH2:false to polling dispatcher

Description (problem / solution / changelog)

Fix: Apply allowH2:false to Telegram polling dispatcher

Root cause: allowH2: false was added to web_fetch in v4.7 to prevent undici from attempting HTTP/2 + IPv6 on Windows (causing 90-200s timeouts and event loop freeze). However, the Telegram polling dispatcher was not updated with this fix.

What changed: Added allowH2: false to all 4 dispatcher creation paths in createTelegramDispatcher():

  • new ProxyAgent() — explicit proxy mode
  • new EnvHttpProxyAgent() — env-proxy mode
  • new Agent() — direct mode (fallback inside env-proxy error handler)
  • new Agent() — direct mode (standard path)

This mirrors the existing HTTP1_ONLY_DISPATCHER_OPTIONS pattern already used in src/infra/net/undici-runtime.ts.

Tests: pnpm test -- --run extensions/telegram/src/fetch.test.ts — 24 tests passed pnpm test -- --run extensions/telegram/src/polling-session.test.ts — 9 tests passed

Refs: GitHub issue #66885

Changed files

  • extensions/telegram/src/fetch.ts (modified, +27/-14)

Code Example

[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
RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

Apply the allowH2: false fix to the Telegram polling dispatcher to prevent undici from attempting HTTP/2 + IPv6 and blocking the event loop.

Guidance

  • Identify the Telegram polling dispatcher configuration and apply the allowH2: false fix to prevent HTTP/2 + IPv6 attempts.
  • Verify that the fix is applied correctly by checking the dispatcher configuration and monitoring the gateway logs for UND_ERR_SOCKET errors.
  • Test the fix by running the gateway and observing the polling behavior to ensure that the stalls are resolved.
  • Consider rolling back to version 2026.4.1 if the fix is not feasible or effective, as this version is known to work without the polling stalls.

Example

No code snippet is provided as the issue is related to a specific configuration fix, and the exact code changes are not specified.

Notes

The issue is specific to Windows environments with IPv6 present but not routable to api.telegram.org, and the fix may not be applicable to other environments. The allowH2: false fix was previously applied to web_fetch/web_search dispatchers in version 4.7, but not to the Telegram polling dispatcher.

Recommendation

Apply the workaround by applying the allowH2: false fix to the Telegram polling dispatcher, as this is the most direct solution to the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

#api#authentication issue#prompt issue#agent setup#task chaining

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING