Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On OpenClaw 2026.4.29, the Telegram channel intermittently times out authenticated Bot API/control requests (getMe, setMyCommands, sendChatAction) and triggers polling-stall recovery even though basic network probes to api.telegram.org from the same host are healthy.

Steps to reproduce

1. Run OpenClaw gateway 2026.4.29 on Ubuntu 26.04/Linux 6.17 with the Telegram channel enabled and multiple Telegram accounts configured (main, john, mike, sam, walt, tim).
2. Restart openclaw-gateway.service.
3. Observe startup/control requests for Telegram providers.
4. Check journalctl --user -u openclaw-gateway for [fetch-timeout], Network request ... failed, and polling-stall recovery lines.

Expected behavior

Telegram provider startup/control requests should complete or fail with a specific actionable network/HTTP error. Multiple Telegram accounts should not produce repeated generic fetch-timeout failures or leave polling in a stalled recovery loop when direct host network probes to Telegram are succeeding.

Actual behavior

After gateway restart, Telegram startup/control requests intermittently time out. The gateway logs repeated generic fetch timeouts, failed command sync/sendChatAction, and polling-stall recovery. This happens while direct host probes to Telegram are healthy.

OpenClaw version

2026.4.29

Operating system

Ubuntu/Linux 6.17.0-22-generic x64

Install method

npm global / systemd user service

Model

openai-codex/gpt-5.5

Provider / routing chain

Telegram channel -> OpenClaw gateway local service -> Telegram Bot API. Model routing is not believed to be involved in the Telegram transport failure.

Additional provider/model setup details

Telegram channel has multiple configured accounts. Global and per-account Telegram network config was set to IPv4-first during troubleshooting:

{"autoSelectFamily": false, "dnsResultOrder": "ipv4first"}

Telegram timeout was set to 30 seconds. The issue still produced fetch-timeout logs after restart.

Logs, screenshots, and evidence

# Gateway restart / startup
May 03 03:31:16 host systemd[1544]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.4.29).
May 03 03:31:51 host node[328854]: 2026-05-03T03:31:51.284+07:00 [gateway] http server listening (7 plugins: acpx, clawrouter, llm-task, lobster, memory-core, memory-wiki, telegram; 32.4s)

# Timeout / Telegram transport symptoms after restart
May 03 03:32:00 host node[328854]: [fetch-timeout] fetch timeout reached; aborting operation
May 03 03:32:00 host node[328854]: [fetch-timeout] fetch timeout reached; aborting operation
May 03 03:32:00 host node[328854]: [fetch-timeout] fetch timeout reached; aborting operation
May 03 03:32:00 host node[328854]: [fetch-timeout] fetch timeout reached; aborting operation
May 03 03:32:00 host node[328854]: [fetch-timeout] fetch timeout reached; aborting operation
May 03 03:32:00 host node[328854]: [fetch-timeout] fetch timeout reached; aborting operation
May 03 03:32:23 host node[328854]: [fetch-timeout] fetch timeout reached; aborting operation

# Earlier same-run details with Telegram methods
May 03 03:03:32 host node[318102]: [telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=none, reason=request-timeout)
May 03 03:03:32 host node[318102]: [telegram] fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=none, reason=request-timeout)
May 03 03:03:32 host node[318102]: 2026-05-03T03:03:32.135+07:00 [telegram] setMyCommands failed: Network request for 'setMyCommands' failed!
May 03 03:03:32 host node[318102]: 2026-05-03T03:03:32.137+07:00 [telegram] command sync failed: HttpError: Network request for 'setMyCommands' failed!
May 03 03:04:33 host node[318102]: 2026-05-03T03:04:33.274+07:00 [telegram] Polling stall detected (no completed getUpdates for 120.28s); forcing restart. [diag inFlight=0 outcome=not-started startedAt=n/a finishedAt=n/a durationMs=n/a offset=n/a]
May 03 03:05:00 host node[318102]: 2026-05-03T03:05:00.037+07:00 [telegram] Polling runner stop timed out after 15s; forcing restart cycle.
May 03 03:05:00 host node[318102]: [telegram] sendChatAction failed: Network request for 'sendChatAction' failed!

# User-observed structured log example, token redacted
warn fetch-timeout {"subsystem":"fetch-timeout"} {"timeoutMs":10000,"elapsedMs":14258,"operation":"fetchWithTimeout","url":"https://api.telegram.org/bot<redacted>/getMe"} fetch timeout reached; aborting operation

# Same host network probes during troubleshooting
ping 192.168.1.1: 60 transmitted, 60 received, 0% packet loss, rtt avg 1.876 ms
ping 1.1.1.1: 60 transmitted, 60 received, 0% packet loss, rtt avg 6.645 ms
ping api.telegram.org: 60 transmitted, 60 received, 0% packet loss, rtt avg 182.611 ms
20x curl -4 https://api.telegram.org/: all succeeded, total about 0.53-0.56s each
20x Node fetch https://api.telegram.org/: all succeeded, about 392-400ms after first call

# Config check after mitigation attempt
channels.telegram.network = { autoSelectFamily: false, dnsResultOrder: 'ipv4first' }
channels.telegram.timeoutSeconds = 30
all Telegram accounts had network = { autoSelectFamily: false, dnsResultOrder: 'ipv4first' }, timeoutSeconds = 30

Impact and severity

Affected: Telegram channel users on this OpenClaw gateway, with multiple Telegram bot/accounts configured.
Severity: Medium to high. Messages can still sometimes send, but Telegram control requests, command sync, chat actions, and polling recovery produce repeated timeouts and noisy/stalled behavior.
Frequency: Intermittent but recurring; during one observed two-hour window there were many [fetch-timeout] lines, and after one restart six timeout lines appeared at the same second, matching the number of configured Telegram accounts.
Consequence: Telegram channel reliability is degraded; polling can stall/restart, command sync can fail, and users see delayed or failed Telegram actions even though host-level connectivity to Telegram appears healthy.

Additional information

This may be related to Telegram transport concurrency or authenticated Bot API control requests rather than generic host network quality. Basic ping/curl/standalone Node fetch to https://api.telegram.org/ from the same host succeeded during troubleshooting, while OpenClaw's Telegram provider continued logging timeouts. The burst of six timeout lines immediately after restart suggests a possible multi-account startup/sync concurrency issue.

Similar existing issues were found around Telegram polling stalls and IPv6/undici behavior, but this report is for Linux 2026.4.29 with IPv4-first already configured and direct network probes healthy.