Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
Severe Node.js Event Loop block (150s+) and delayed IPv4 fallback in Telegram plugin on IPv6-disabled/unroutable networks.
Steps to reproduce
Run OpenClaw on a host/network where IPv6 is present but unroutable, or disabled at the host OS level (e.g., Home Assistant OS).
Ensure the Telegram plugin is enabled.
Start or restart the OpenClaw gateway.
Observe the startup time and check the logs for health-monitor liveness warnings and fetch timeouts.
Expected behavior
The gateway should start quickly. The Telegram plugin should gracefully and immediately fall back to IPv4 (e.g., using autoSelectFamily: true in Node's fetch/undici) without blocking the main event loop.
Actual behavior
The gateway freezes completely for over 2.5 minutes during startup. The Telegram plugin tries to connect to api.telegram.org using IPv6 (AAAA record), waits for system TCP timeouts (ETIMEDOUT, ENETUNREACH), and heavily blocks the Node.js event loop (reaching up to 149,787 ms delay).
The built-in fallback (enabling sticky IPv4-only dispatcher) eventually triggers, but way too late — only after the gateway has been paralyzed. Additionally, the standard Node.js workaround is explicitly blocked by the addon.
OpenClaw version
2026.4.29
Operating system
Home Assistant OS (Linux 6.12.77-haos) running via Docker on Intel i5 NUC.
Install method
No response
Model
openrouter/z-ai/glm-5.1
Provider / routing chain
OpenRouter
Additional provider/model setup details
No response
Logs, screenshots, and evidence
2026-05-01T19:24:16.709+03:00 [ws] ⇄ res ✓ models.list 159998ms conn=ddf082df…8164 id=880449c8…dcd4
[telegram] fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=none, reason=request-timeout)
2026-05-01T19:24:16.789+03:00 [diagnostic] liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=172s eventLoopDelayP99Ms=149787 eventLoopDelayMaxMs=149787 eventLoopUtilization=1 cpuCoreRatio=0.993 active=0 waiting=0 queued=0
[telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
WARN: Reserved environment variable 'NODE_OPTIONS' cannot be overridden via gateway_env_vars (skip)
Impact and severity
High / Severe. It completely blocks the Gateway and Control UI from loading for several minutes on every restart. Network issues in one plugin shouldn't block the main event loop and paralyze the entire core.
Additional information
Since the standard workaround is blocked by the gateway configuration (Reserved environment variable 'NODE_OPTIONS' cannot be overridden via gateway_env_vars, which prevents users from passing --dns-result-order=ipv4first), users have no way to mitigate this themselves.
Consider implementing autoSelectFamily: true / autoSelectFamilyAttemptTimeout in your HTTP client (undici / fetch) to handle dual-stack IPv4/IPv6 gracefully and instantly.
Additional information
No response
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
Severe Node.js Event Loop block (150s+) and delayed IPv4 fallback in Telegram plugin on IPv6-disabled/unroutable networks.
Steps to reproduce
Run OpenClaw on a host/network where IPv6 is present but unroutable, or disabled at the host OS level (e.g., Home Assistant OS).
Ensure the Telegram plugin is enabled.
Start or restart the OpenClaw gateway.
Observe the startup time and check the logs for health-monitor liveness warnings and fetch timeouts.
Expected behavior
The gateway should start quickly. The Telegram plugin should gracefully and immediately fall back to IPv4 (e.g., using autoSelectFamily: true in Node's fetch/undici) without blocking the main event loop.
Actual behavior
The gateway freezes completely for over 2.5 minutes during startup. The Telegram plugin tries to connect to api.telegram.org using IPv6 (AAAA record), waits for system TCP timeouts (ETIMEDOUT, ENETUNREACH), and heavily blocks the Node.js event loop (reaching up to 149,787 ms delay).
The built-in fallback (enabling sticky IPv4-only dispatcher) eventually triggers, but way too late — only after the gateway has been paralyzed. Additionally, the standard Node.js workaround is explicitly blocked by the addon.
OpenClaw version
2026.4.29
Operating system
Home Assistant OS (Linux 6.12.77-haos) running via Docker on Intel i5 NUC.
Install method
No response
Model
openrouter/z-ai/glm-5.1
Provider / routing chain
OpenRouter
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
High / Severe. It completely blocks the Gateway and Control UI from loading for several minutes on every restart. Network issues in one plugin shouldn't block the main event loop and paralyze the entire core.
Additional information
Since the standard workaround is blocked by the gateway configuration (Reserved environment variable 'NODE_OPTIONS' cannot be overridden via gateway_env_vars, which prevents users from passing --dns-result-order=ipv4first), users have no way to mitigate this themselves.
Consider implementing autoSelectFamily: true / autoSelectFamilyAttemptTimeout in your HTTP client (undici / fetch) to handle dual-stack IPv4/IPv6 gracefully and instantly.
Additional information
No response