Bug Report: openclaw 2026.4.25 — Telegram polling broken + model fallback unusable

Repo: https://github.com/openclaw/openclaw Affected versions: 2026.4.24, 2026.4.25 (both regressions appear after 2026.4.23) Last known good: 2026.4.23 Workaround: npm i -g [email protected] Platform: Windows 11, Node 22.21.1

Multiple users on Windows are reporting both issues. Filing them together because they surface together (telegram failing + model fallback cascading), but they're independent regressions.

Bug 1: Telegram polling completely broken in 2026.4.25

getUpdates and sendMessage fail with Network request for '<endpoint>' failed!. The polling runner enters an infinite restart loop. Agents appear unresponsive — first message after the gateway boots may sneak through, then nothing.

Symptoms (from gateway log)

[telegram] Polling stall detected (active getUpdates stuck for 138.99s); forcing restart.
[telegram] [diag] polling cycle finished reason=polling stall detected ... error=Network request for 'getUpdates' failed!
[telegram] polling runner stopped (polling stall detected); restarting in 3.99s.
... (this repeats for every channel/agent, in tight loops)
[telegram] sendMessage failed: Network request for 'sendMessage' failed!
[telegram] final reply failed: HttpError: Network request for 'sendMessage' failed!
[diagnostic] stuck session: sessionId=... sessionKey=agent:alex:main state=processing age=415s queueDepth=1

Reproduction

1. Install [email protected].
2. Configure any agent with a Telegram channel.
3. Send a message via Telegram. Receive at most one reply.
4. Subsequent messages: typing indicator may show briefly, then nothing. Session sits in state=processing indefinitely.

Workaround

npm i -g [email protected]

Telegram polling and sendMessage resume working within seconds of the rolled-back gateway booting. Confirmed across multiple users.

Probable area

Something in the Telegram transport layer between 2026.4.23 and 2026.4.25. The [telegram] [diag] logging is new and points at transport rebuilds, but the rebuilds don't recover because every subsequent getUpdates also fails. Worth comparing the telegram plugin's HTTP/transport setup between those versions.

Bug 2: Model fallback cascade burns ~30 seconds per invalid model

When the configured primary or fallback model returns a non-retryable error (e.g. OpenRouter 400 not a valid model ID), each attempt takes ~30 seconds before falling through to the next candidate. With a 3-entry fallback chain, a single agent turn can stall for 90+ seconds while cycling through the whole chain.

Symptoms

For a turn where primary + 2 fallbacks all return 400:

14:58:37 [agent/embedded] embedded run agent end: ... isError=true model=zhipuai/glm-4-air:free ... error=400 zhipuai/glm-4-air:free is not a valid model ID
14:58:37 [diagnostic] lane task error: lane=session:agent:alex:... durationMs=40277 error="FailoverError: 400 ..."
14:59:11 [agent/embedded] embedded run agent end: ... isError=true model=zhipuai/glm-5.1 ... error=400 zhipuai/glm-5.1 is not a valid model ID
14:59:11 [diagnostic] lane task error: lane=session:agent:alex:... durationMs=33798 error="FailoverError: ..."
14:59:41 [agent/embedded] embedded run agent end: ... isError=true model=minimax/minimax-m2.7 ... error=Reasoning is required for this model endpoint
... finally succeeds at 15:00:45 — over 2 minutes after the user sent the message

The session is held in processing for the entire cascade duration, blocking other turns.

Why this matters

A 400 invalid model ID is a deterministic, fast-failing error from the provider. There's no reason to spend 30+ seconds on it before falling through. In 2026.4.23, the same chain (with the same invalid IDs) failed over within a few seconds total.

Probable area

embedded run failover decision / model-fallback/decision flow. The 30s+ duration suggests an internal retry or timeout wrapping the provider error before fallback fires. That retry should not apply to non-retryable status codes (400, 401, 404).

Repro

1. Configure any agent with a fallback chain containing intentionally invalid OpenRouter model IDs (e.g. openrouter/zhipuai/glm-5.1 — note: zhipuai rebranded to z-ai/ on OpenRouter, so the old IDs all return 400).
2. Send a message.
3. Observe durationMs=30000+ per invalid candidate before the next fallback fires.

Environment

openclaw: 2026.4.25 (broken) → rolled back to 2026.4.23 (working)
node: 22.21.1
os: Windows 11 Pro N (10.0.26200)
launcher: Pinokio (clawdbot)
plugins: telegram, browser, device-pair, phone-control, talk-voice

Notes for maintainers

• Happy to provide full gateway logs, sessions.json, or run a diff between 2026.4.23 and 2026.4.25 if useful.
• Confirmed both bugs reproduce on a fresh 2026.4.25 install; both disappear on 2026.4.23 rollback.
• 2026.4.24 is also blocked locally due to a Windows ESM regression (Telegram channel loader passing raw C:\... paths to Node 22's strict ESM loader, throwing Received protocol 'c:'). Probably worth looking at telegram-related changes across .24 and .25 together.