[Bug]: Telegram inbound message can be re-queued on model fallback/rate-limit, causing duplicate user turns and missing outbound delivery #26764
Description
Summary
Under API rate-limit/fallback conditions, a single inbound Telegram message is sometimes re-queued as duplicate user turns in Control UI, and in some cases Control UI shows assistant output but Telegram receives no visible reply.
Steps to reproduce
- Run OpenClaw 2026.2.24 with Telegram channel enabled.
- Trigger model congestion/rate-limit window (HTTP 429 / RESOURCE_EXHAUSTED).
- Send one Telegram message (example: "Please remember this.").
- Check Control UI session timeline and Telegram client output.
Expected behavior
A single inbound Telegram message should map to one user turn even during fallback/retry. If delivery fails, it should end as explicit failed delivery, not silently remain UI-only.
Actual behavior
The same Telegram input can appear as duplicated user turns (short interval, e.g. ~20s). Sometimes assistant activity/output appears in Control UI but no visible Telegram reply is sent.
OpenClaw version
2026.2.24
Operating system
Ubuntu Server host + Debian-based OpenClaw container
Install method
No response
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
Observed around 2026-02-26 02:16 JST (2026-02-25 17:16 UTC). Logs show repeated 429 RESOURCE_EXHAUSTED / API rate limit errors. For one single Telegram input ("Please remember this."), session shows two user turns:
- 2026-02-25T17:16:17.606Z
- 2026-02-25T17:16:37.670Z
Single OpenClaw container was running (no multi-instance Telegram polling conflict observed).