Skip to content

fix(gateway): streaming truncation on Telegram flood control - #4650

Closed
kshitijk4poor wants to merge 1 commit into
NousResearch:mainfrom
kshitijk4poor:fix/telegram-stream-truncation
Closed

fix(gateway): streaming truncation on Telegram flood control#4650
kshitijk4poor wants to merge 1 commit into
NousResearch:mainfrom
kshitijk4poor:fix/telegram-stream-truncation

Conversation

@kshitijk4poor

Copy link
Copy Markdown
Collaborator

Summary

Fixes truncated streaming responses on Telegram when flood control hits during progressive message edits.

Problem

When streaming is enabled, Hermes progressively edits a single Telegram message with incoming tokens. If Telegram rate-limits an editMessageText call mid-stream:

  1. The stream consumer disables further edits (_edit_supported = False)
  2. But _already_sent stays True
  3. The handler sees already_sent=True and skips the normal final send
  4. The user is left with whatever partial text was last successfully edited

Fix

stream_consumer.py: Reset _already_sent = False when an edit fails, so the handler's normal send path delivers the complete response.

telegram.py: Return SendResult(success=False) for flood control waits >5s instead of blocking the caller. This lets the stream consumer see the failure immediately and fall back cleanly, rather than blocking for 23s+ and potentially getting cancelled by the 5-second cleanup timeout.

Test plan

  • pytest tests/gateway/ — 1838 passed, 9 failed (all pre-existing)
  • Send a message that triggers a long streaming response while the bot is near Telegram's rate limit → response should arrive complete via normal send, not truncated

When Telegram rate-limits edit_message during streaming, the stream
consumer disabled further edits but left _already_sent=True. The
handler then skipped the normal final send, leaving the user with a
truncated partial response.

Two changes:
- stream_consumer.py: reset _already_sent=False when an edit fails,
  so the handler's normal send path delivers the complete response
- telegram.py: return SendResult(success=False) for flood control
  waits >5s instead of blocking, so the stream consumer sees the
  failure and can fall back cleanly
@teknium1

teknium1 commented Apr 3, 2026

Copy link
Copy Markdown
Contributor

Superseded by #4727 which includes this fix alongside the full reliability cluster from #4577. Credit to @kshitijk4poor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants