Summary
When streaming: "partial" is enabled on Telegram and a model fallback occurs mid-stream (e.g., primary model hits 429 rate limit), the response is silently dropped — the user receives nothing.
Steps to Reproduce
- Set
channels.telegram.streaming: "partial"
- Configure a primary model (e.g.,
google/gemini-flash-latest) with fallbacks
- Send a message that triggers a slow/long response
- Primary model hits 429 rate limit ~14s into processing
- Gateway falls back to secondary model (e.g.,
anthropic/claude-sonnet-4-6)
- Secondary model generates and completes the response
Expected: User receives the completed response from the fallback model.
Actual: User receives nothing. Response is silently dropped.
Root Cause (from cache-trace logs)
When partial streaming is active, a draft message is sent to Telegram immediately using the primary model's output. When the primary model fails and a fallback takes over, the gateway attempts to edit the existing draft message with the new response. If the Telegram draft has expired or the edit fails (e.g., due to timing), the failure appears to be silent — no retry, no new message sent.
Evidence from session logs:
18:36:29 — User message received, processed by gemini-flash-latest
18:36:44 — Model snapshot changes to claude-sonnet-4-6 (fallback)
18:39:43 — Assistant response written to session store
- User receives no message on Telegram
Requested Fix
When a model fallback occurs mid-stream and the draft edit fails (any error from Telegram API), the gateway should:
- Detect the delivery failure
- Send the completed response as a new message (instead of editing the failed draft)
- Optionally: delete the stale partial draft before sending the new message
This would make fallbacks seamless and invisible to the user.
Environment
- OpenClaw v2026.3.8
- Channel: Telegram
- Primary model:
google/gemini-flash-latest
- Fallback model:
anthropic/claude-sonnet-4-6
streaming: "partial"
retry: { attempts: 5, minDelayMs: 2000, maxDelayMs: 30000, jitter: 0.3 }
Summary
When
streaming: "partial"is enabled on Telegram and a model fallback occurs mid-stream (e.g., primary model hits 429 rate limit), the response is silently dropped — the user receives nothing.Steps to Reproduce
channels.telegram.streaming: "partial"google/gemini-flash-latest) with fallbacksanthropic/claude-sonnet-4-6)Expected: User receives the completed response from the fallback model.
Actual: User receives nothing. Response is silently dropped.
Root Cause (from cache-trace logs)
When
partialstreaming is active, a draft message is sent to Telegram immediately using the primary model's output. When the primary model fails and a fallback takes over, the gateway attempts to edit the existing draft message with the new response. If the Telegram draft has expired or the edit fails (e.g., due to timing), the failure appears to be silent — no retry, no new message sent.Evidence from session logs:
18:36:29— User message received, processed bygemini-flash-latest18:36:44— Model snapshot changes toclaude-sonnet-4-6(fallback)18:39:43— Assistant response written to session storeRequested Fix
When a model fallback occurs mid-stream and the draft edit fails (any error from Telegram API), the gateway should:
This would make fallbacks seamless and invisible to the user.
Environment
google/gemini-flash-latestanthropic/claude-sonnet-4-6streaming: "partial"retry: { attempts: 5, minDelayMs: 2000, maxDelayMs: 30000, jitter: 0.3 }