Environment

• OpenClaw version: 2026.3.28
• OS: Debian 13, Linux 6.12.74
• Node: v22.22.0
• IPv4 forced via systemd drop-in: NODE_OPTIONS=--dns-result-order=ipv4first

Problem

The Telegram getUpdates long-poll socket stalls for 90–110 seconds intermittently, even though:

• Direct curl -4 https://api.telegram.org from the same host returns in 33ms
• The ipv4-fix.conf drop-in with NODE_OPTIONS=--dns-result-order=ipv4first is active
• No rate limiting or Telegram-side errors

After each stall, the gateway logs rebuilding transport for next polling cycle and recovers. But stalls recur every 7–20 minutes in active sessions.

Observed stall durations (2026-03-30)

10:02 — 110s
16:12 — 90s
16:19 — 100s
16:21 — 95s
16:29 — 95s
17:02 — 109s

Very consistent 90–110s range. Never shorter, never much longer.

Log pattern

[telegram] Polling stall detected (active getUpdates stuck for 100.04s); forcing restart.
[diag inFlight=1 outcome=started startedAt=... finishedAt=... durationMs=30020 offset=... error=Network request for 'getUpdates' failed!]
[telegram] polling runner stopped (polling stall detected); restarting in 4.09s.
...
[telegram] [diag] rebuilding transport for next polling cycle

During and after each stall, sendMessage and sendChatAction also fail:

[telegram] sendChatAction failed: Network request for 'sendChatAction' failed!
[telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!

What is NOT the cause

• Telegram servers: reachable in 33ms via IPv4
• IPv6: broken on this VPS (curl -6 times out at 5s), but IPv4 is forced via NODE_OPTIONS so this should be irrelevant
• Memory: RSS ~160–480MB, well within limits
• OOM: no OOM kills during stall events

Hypothesis

The 90–110s duration is suspiciously consistent and matches typical undici/fetch headersTimeout or bodyTimeout defaults. The gateway appears to open a connection, initiate the getUpdates long-poll (with Telegram timeout=30s), but the socket then silently hangs — not receiving the Telegram response OR the timeout response — until undicis internal socket timeout fires.

This could be a stale connection pool socket issue: undici reuses keep-alive connections, and if a connection goes idle and the far end closes it (Telegram servers do close idle connections), the next request on that socket hangs until the OS-level TCP timeout.

After rebuilding transport, the next few cycles work fine — consistent with a fresh connection pool clearing the stale socket.

Question

Is there a way to configure the undici pool used for Telegram polling to:

1. Set a lower keepAliveTimeout to avoid stale connections
2. Or disable connection reuse for the polling socket specifically
3. Or set a headersTimeout / bodyTimeout shorter than the current apparent ~100s default

Alternatively — is the getUpdates long-poll timeout parameter being set to something > 30s? If the Telegram API timeout param is 30s but undicis socket timeout is ~90s, and the TCP connection drops mid-poll, undici would wait up to its socket timeout before giving up.

Workaround

None found. The stalls recur after every rebuilding transport cycle.