Bug type

Crash (process/app exits or hangs)

Summary

Telegram polling can enter a stuck state after a stall is detected: gateway remains running, but inbound getUpdates consumption stops until a manual gateway restart.

Steps to reproduce

1. Configure Telegram in polling mode (not webhook) and run gateway:
   • channels.telegram.enabled=true
   • channels.telegram.proxy=http://<proxy>:7890 (optional but this setup reproduces more often)
2. Let polling run under intermittent network/proxy instability (long-poll request stalls).
3. Observe logs:
   • first stall: Polling stall detected ... forcing restart followed by Telegram polling runner stopped ... restarting ...
   • later stall: Polling stall detected ... forcing restart appears again, but restart sequence does not complete.
4. Send DM to bot from a previously authorized user.
5. Verify gateway still reports Telegram running, but inbound is stale and updates accumulate at Telegram API until manual restart.

Expected behavior

When a stall is detected, polling cycle should always teardown fully and start a fresh cycle. Inbound updates should resume automatically without manual service restart.

Actual behavior

After stall detection, polling can hang in stop/teardown path. Gateway process remains alive and reports Telegram as running, but inbound updates are no longer consumed.

OpenClaw version

2026.3.8 (3caab92)

Operating system

AlmaLinux 9.6 (kernel 5.14.0-570.55.1.el9_6.x86_64)

Install method

npm global ([email protected])

Model

N/A (channel polling bug; model selection does not affect reproduction)

Provider / routing chain

openclaw gateway -> Telegram Bot API (grammY polling runner) with proxy fetch enabled

Config file / key location

~/.openclaw/openclaw.json

• channels.telegram.proxy = "http://<redacted>:7890"
• channels.telegram.network.autoSelectFamily = true
• channels.telegram.dmPolicy = "pairing"

Additional provider/model setup details

Not model/provider specific. This reproduces in channel transport layer before model invocation.

Logs, screenshots, and evidence

Redacted excerpts from /tmp/openclaw/openclaw-2026-03-11.log:

2026-03-11T15:33:44+08:00 [telegram] Polling stall detected (no getUpdates for 97.27s); forcing restart.
2026-03-11T15:33:44+08:00 Telegram polling runner stopped (polling stall detected); restarting in 2.24s.

2026-03-11T15:35:19+08:00 [telegram] Polling stall detected (no getUpdates for 90s); forcing restart.
# (no corresponding "polling runner stopped ... restarting ..." afterwards)

Status later still reported Telegram as running while inbound age was stale:

Gateway reachable.
- Telegram default: enabled, configured, running, in:6h ago, mode:polling, bot:@<redacted>, token:config, works

At the same time, Telegram API still had pending updates for the bot (not consumed by gateway) until systemctl --user restart openclaw-gateway.

Impact and severity

• Affected: Telegram channel users on polling mode.
• Severity: High (blocks inbound message handling).
• Frequency: Intermittent (observed multiple times in one day under unstable network/proxy conditions).
• Consequence: Users send messages but bot appears silent; operationally requires manual restart.

Additional information

• Last known good: unknown.
• First observed on 2026-03-11 with 2026.3.8.
• Local mitigation that resolved it: in stall path, call both runner.stop() and bot.stop(), and add a stop-timeout fallback to force cycle restart if stop hangs.