fix(telegram): prevent rapid-fire edits and streaming suppression after tool calls

[elphamale]

Summary

Fixes three bugs that caused Telegram streaming to stall mid-response or deliver plain-text markdown during streaming.

• buffer_threshold bypassed edit_interval — the OR condition len(accumulated) >= threshold fired every ~60ms for fast LLMs, triggering 100 s+ Telegram flood-control penalties and entering fallback mode (user sees no streaming until full answer arrives). Fix: require elapsed >= min(edit_interval, 1.0) on the buffer-threshold branch so rapid LLM output cannot fire edits faster than the platform's per-chat rate limit.

• should_hold_streaming_for_rich suppressed all streaming after tool calls — when the LLM's final response started with a table and no message was on screen yet (_message_id is None), the hold blocked every streaming tick until got_done. Fix: return False — MarkdownV2 streaming handles partial tables gracefully (incomplete rows pass as raw text; complete tables render via _wrap_markdown_tables), so suppression causes worse UX than partial rendering — particularly for tool-call responses where the user would see nothing at all until the full answer arrived.

• Streaming ticks sent plain text — edit_message(finalize=False) had no parse_mode, so MarkdownV2 markup rendered as raw **bold** characters during streaming. Fix: try MarkdownV2 first via format_message(), fall back to plain text only on BadRequest; non-BadRequest errors (flood, network) propagate to the outer handler as before.

Also adds finalize=True to the _send_fallback_final edit-in-place (introduced in #53865) so stale partial messages are replaced with fully formatted content rather than plain text.

Test plan

• tests/gateway/test_stream_consumer_rich_hold.py — finalize=True in fallback, buffer-threshold 1 s floor, rich-hold mechanism (9 tests)
• tests/gateway/test_telegram_streaming_tick.py — MarkdownV2 streaming tick, BadRequest plain-text fallback, flood-error propagation, should_hold_streaming_for_rich always-False (9 tests)
• Manually verified in group chat: streaming no longer stalls at table headers or after tool calls

Update: rebased onto main, fixed the buffer_threshold floor properly, dropped rich-hold (addresses hermes-sweeper review)

This branch was 275 commits behind origin/main (it shared its first four commits with #53865's original branch, before that PR was rebased). Rebased directly onto origin/main — the earlier "stacked on #53865" framing no longer applies literally; the two PRs share duplicate underlying commits rather than one being a git-level stack on the other, since #53865 was rebased independently. The rebase itself cleanly resolved the same _try_strip_cursor conflict already worked out in #53865 (origin/main's 04898631c/4aa499ff9 had independently converged on the same "leave message intact" behavior).

buffer_threshold floor — corrected further. sweeper found that min(edit_interval, 1.0) doesn't actually provide the stated one-second floor for a short configured edit_interval (e.g. 0.1s): min(0.1, 1.0) = 0.1, so the floor silently collapses back to the short interval exactly when it should be protecting against it. Fixed with a fixed 1.0 constant — not max(edit_interval, 1.0), which was my first instinct but turns out to break the other documented behavior this branch's own test (test_buffer_waits_1s_before_firing) already encodes: a long configured edit_interval (e.g. 10s) should still let a full buffer flush early at the 1-second mark instead of waiting the whole interval — that's the entire point of this early-fire branch. max() would force it to wait the full 10s instead. A bare 1.0 fixes the short-interval bug while leaving the long-interval behavior byte-for-byte unchanged (min(10.0, 1.0) == 1.0 == the new constant).

One honest caveat: for configured intervals below 1 second specifically, this fix has no independently observable effect on stream timing — the interval-based should_edit branch immediately above it already fires at the same or an earlier elapsed time with a strictly weaker bar (any accumulated text, vs. buffer_threshold characters), so it dominates regardless of what the buffer_threshold branch's own floor is set to. The fix is still correct and worth making — it's the difference between the code actually satisfying its own documented "at least 1 second regardless of edit_interval" contract instead of only claiming to, and it removes a latent inconsistency that could matter if the interval-branch's behavior ever changes independently — but it isn't testable via stream-timing assertions in that regime, so no test claims to observe it there.

Also fixed test_buffer_waits_1s_before_firing itself, which had a pre-existing bug unrelated to sweeper's finding: it asserted on the very first-ever flush, which always fires immediately regardless of any floor logic (_last_edit_time starts at 0.0, so "elapsed since last edit" is enormous on the first tick — correct UX, first content should appear ASAP, but not what this test meant to check). Confirmed via git stash that this test failed identically on the code as originally written, before any of my changes. Rewrote it to check the floor against a second flush, after an initial one establishes a realistic _last_edit_time baseline.

Dropped the rich-hold mechanism. sweeper flagged should_hold_streaming_for_rich as dead extension surface: Telegram (the only adapter) always returns False, by explicit design, so the consumer's _rich_hold state, the hold-check block, and three dedicated test classes had no live production behavior at all. Removed the hook, the consumer-side state, Telegram's always-False stub, and the tests (TestRichHold, test_rich_hold_initialised_false, TestShouldHoldStreamingForRich). Renamed test_stream_consumer_rich_hold.py — which no longer has anything to do with rich-hold — to test_stream_consumer_fallback_finalize_and_buffer_floor.py. Reintroduce the hook if a concrete adapter actually needs and enables it.

Confirmed test_telegram_streaming_tick.py::test_streaming_tick_flood_propagates is a separate, pre-existing failure (already flagged as an undiagnosed design question in this PR's own comment history) unrelated to either fix, and the usual 9 telegram test-order-pollution failures elsewhere in the suite are unrelated (same ones confirmed against a clean origin/main in earlier PRs this session).

🤖 Generated with Claude Code

[alt-glitch]

This was generated by AI during triage.

Related: Telegram streaming/draft-flood cluster. Stacked on #53865 (fix/telegram-draft-flood-cascade); test-coverage follow-ups for the same edge cases live in issue #54275 and PR #54286. Once #53865 merges, this reduces to the single streaming-formatting commit. Reviewers should sequence after #53865.

[elphamale]

Rebased onto current origin/main — the branch was stale (created/abandoned 2026-06-28) and main had independently gained a0a3c716fc (dedup saturated mid-stream overflow previews) touching the same edit_message call site this PR rewrites for MarkdownV2 streaming ticks. Resolved by keeping main's saturation-dedup cache write and layering this PR's MarkdownV2-first + BadRequest-fallback formatting across all three success exits of that block.

Also found and fixed one thing already latent in this PR before the rebase (confirmed pre-existing on the original branch, not introduced by the rebase): should_hold_streaming_for_rich was checked with a truthy test in stream_consumer.py; a bare MagicMock() test adapter auto-vivifies that attribute as a callable returning a truthy Mock, silently activating rich-hold in ~20 unrelated tests using unspec'd mock adapters (mostly in test_stream_consumer.py). Production is unaffected (the real adapter always returns False there) — switched to a strict is True check, which fixed those ~20.

Also updated tests/gateway/test_telegram_format.py::test_non_final_edit_uses_plain_text_without_markdown, which asserted the old plain-text streaming-tick behavior this PR intentionally replaces — split into two tests covering the MarkdownV2-success and BadRequest-fallback paths.

Full tests/gateway/ suite: 19 failed/9003 passed — exactly the 13-failure established repo-wide baseline plus 6 failures already present in this branch's own new test files before this rebase (confirmed on the original, pre-rebase branch tip):

• 3x test_stream_consumer.py::TestSegmentBreakOnToolBoundary::test_fallback_final_*
• 2x test_stream_consumer_rich_hold.py (the is True fix above didn't touch these — they have their own separate issue, not yet diagnosed)
• 1x test_telegram_streaming_tick.py::test_streaming_tick_flood_propagates — looks like a genuine design question (should a streaming-tick flood retry inline or fail fast?) rather than an obvious bug

None of the 6 are regressions from this rebase — flagging rather than fixing since diagnosing them wasn't part of this rebase's scope.

[teknium1]

Thanks for addressing two behaviors that are still present on current main: gateway/stream_consumer.py:638 lets buffer_threshold bypass the edit interval, and plugins/platforms/telegram/adapter.py:4002-4007 sends non-final ticks without MarkdownV2 formatting.

Problems

• gateway/stream_consumer.py:656 uses min(self._current_edit_interval, 1.0). A configured edit_interval=0.1 still permits threshold-driven updates every 0.1 seconds, so this does not provide the stated one-second protection.
• The new rich-hold extension has no live consumer: plugins/platforms/telegram/adapter.py:1502 always returns False, while the consumer only holds when the hook returns True (gateway/stream_consumer.py:675-684). This is dead extension surface and dedicated test coverage without production behavior.

Suggested changes

• Define the rate-limit behavior explicitly for Telegram and make the threshold guard satisfy that contract for sub-second configured intervals.
• Drop the rich-hold hook/state/tests unless a concrete adapter needs and enables it.
• Salvage narrowly against the later fallback recovery changes already on main (04898631c, 4aa499ff9).

Automated hermes-sweeper review.

[teknium1]

min() does not establish a one-second floor: with edit_interval=0.1, this condition still fires every 0.1 seconds once the threshold is reached. Please scope the Telegram limit explicitly or use a condition that actually satisfies the documented cadence contract.

[teknium1]

This always returns False, so the new generic should_hold_streaming_for_rich machinery cannot affect production Telegram behavior. Please remove the dead hook/state/tests unless a concrete adapter needs to opt into it.

[elphamale]

Fixed both, pushed ea9b045a2 (also rebased this branch onto origin/main — it was 275 commits behind, sharing early history with #53865's pre-rebase branch).

buffer_threshold floor: confirmed — min(edit_interval, 1.0) collapses back to the raw interval whenever it's under a second, silently dropping the floor. My first fix was max(edit_interval, 1.0), but that breaks this branch's own test_buffer_waits_1s_before_firing, which validates that a long configured interval (10s) should still let a full buffer flush early at the 1s mark rather than waiting the whole interval — the entire point of this branch. Went with a bare 1.0 constant instead: fixes the short-interval bug you flagged, leaves the long-interval behavior unchanged (min(10.0, 1.0) and the new constant are both 1.0).

One thing I want to flag rather than quietly gloss over: for configured intervals below 1 second, this fix has no independently observable effect on stream timing — the plain interval-based should_edit check right above it already fires at the same or earlier elapsed time with a weaker bar (any accumulated text vs. buffer_threshold characters), so it dominates regardless of what this branch's floor is set to. The fix is still correct — it's the difference between the code actually satisfying its own documented contract vs. only claiming to, and it matters if that other branch's behavior ever changes independently — but I didn't want to claim a timing-based regression test proves something it can't actually observe. Separately, found and fixed a real, pre-existing bug in test_buffer_waits_1s_before_firing itself (asserted on the very first-ever flush, which always fires immediately regardless of any floor — confirmed via git stash this failed identically before any of my changes).

Rich-hold: removed entirely — hook, consumer state, Telegram's always-False stub, and the three dead-code test classes. Renamed the now-misleadingly-named test file.

[elphamale]

Rebased onto the current tip of #53865 (fix/telegram-draft-flood-cascade), which this branch had drifted apart from since neither has merged yet (today's PR-conflict-drift audit flagged this pair).

All 7 of this PR's own commits replayed cleanly on top of #53865's sendMessageDraft-failure-handling fixes. Conflict resolution, commit by commit:

• _try_send_rich_draft draft-failure handling / sendMessageDraft result semantics — kept fix(telegram): prevent draft-failure cascade that causes 4-minute flood-control silence #53865's behavior throughout (ok=False counts toward _MAX_DRAFT_FAILURES instead of being silently treated as success; the cooldown fields _draft_cooldown_until/_last_draft_retryable). This PR's own later commit (e0eefbd84, "prevent rapid-fire edits...") independently re-adds a _rich_hold field on top of that, which its own final commit (8de96e84a, "buffer_threshold 1-second floor + drop dead rich-hold hook") then removes again — so the end state matches this PR's own intended history, just layered on fix(telegram): prevent draft-failure cascade that causes 4-minute flood-control silence #53865's fixed foundation instead of the old cascading-failure code.
• _try_strip_cursor — kept fix(telegram): prevent draft-failure cascade that causes 4-minute flood-control silence #53865's "leave the message intact on any failure" design rather than this PR's older delete-the-partial-message fallback. Confirmed via e0eefbd84's own commit message, which explicitly reverts that same delete-fallback ("a partial message with a stuck cursor is better UX") — so this isn't a call I made unilaterally, it's this PR's own later self-correction, just applied earlier in the rebase.
• tests/gateway/test_stream_consumer_draft.py, test_telegram_send_draft_flood_control.py, test_telegram_send_draft_format.py — resolved by keeping fix(telegram): prevent draft-failure cascade that causes 4-minute flood-control silence #53865's versions, which are a strict superset (e.g. test_telegram_send_draft_flood_control.py's incoming side asserted the opposite retryable value for an identical short-flood-then-fail scenario than fix(telegram): prevent draft-failure cascade that causes 4-minute flood-control silence #53865's already-validated version — discarded in favor of the tested, shipped behavior).

Also found and fixed a pre-existing bug in this PR's own test suite, unrelated to the rebase: test_telegram_streaming_tick.py::test_streaming_tick_flood_propagates used retry_after=2, which actually falls into edit_message()'s long-standing (pre-dating both PRs) ≤5s inline-retry-then-succeed path — so success=True is the correct, existing behavior, not the failure the test asserted. Confirmed this fails identically on the original pre-rebase tip in isolation. Fixed by moving the propagation-case test to a >5s wait (where the code genuinely returns failure without retrying) and adding a companion test for the short-wait retry-and-succeed case.

Full sweep after the fix: test_telegram_streaming_tick.py, test_telegram_send_draft_format.py, test_stream_consumer_fallback_finalize_and_buffer_floor.py, test_stream_consumer_draft.py, test_telegram_send_draft_flood_control.py, test_stream_consumer.py — 181/181 passing. check-windows-footguns.py --diff origin/main clean. Force-pushed with a verified lease (remote was still at the pre-rebase tip).

[GottZ]

This was generated by AI during triage.

Summary

Three PRs address or reference Telegram streaming truncation and flood-control behavior: #4650 restores final-send fallback after failed edits, #7683 adds merged adaptive backoff and reliable continuation delivery, and #54331 extends the current draft/edit paths with cooldown handling, threshold pacing, finalized fallback edits, and MarkdownV2 streaming ticks.

Related pull requests

• #4650 [closed] related — (+9/-5) — superseded: This directly fixes the original truncation path by marking a failed progressive edit as not delivered and returning immediately on long Telegram flood waits, but it remains relevant as the minimal reference implementation superseded by #4727.
• #7683 [merged] related — (+117/-25) — merged reference implementation: This merged the broader edit-stream reliability fix—adaptive flood backoff, overflow preservation, cursor cleanup, fallback-send retry, and a safer default interval—covering the same failed-edit truncation cause more comprehensively than #4650.
• #54331 related — (+1486/-90) — keep open for narrow salvage: The diff adds useful current-path fixes for MarkdownV2 streaming ticks, draft RetryAfter cooldowns, and finalized edit-in-place fallback, but it also carries a large stacked draft-flood cluster and its fixed 1-second threshold guard does not stop the independent interval branch from emitting every 0.1 seconds when configured that way. Consistent with the contributor keep_open review on #54331, it should be narrowed and the Telegram pacing contract completed before merge.

Duplicates

#4650 and the merged #7683 substantially overlap on failed-edit flood-control truncation, with #7683 providing the broader implementation; #54331 overlaps that reliability area but also contains distinct draft-transport and streaming-formatting changes.

Suggested consolidation

Merge #54331 only after narrowing it to behavior still missing after #7683 and its #53865 base, and after enforcing the stated Telegram pacing contract across both threshold- and interval-triggered ticks; this follows the keep_open review on #54331 rather than overriding it. #4650 can remain closed as superseded, while merged #7683 should remain the reference implementation rather than be treated as a closure candidate.

Cross-PR triage: Reviewed 3 pull requests and 0 issues in this complex. Each diff was read against this issue; Assessment working set: 102 kB of PR diffs, 10 kB of issue/PR text, 9 kB of discussion (6 comments), 1 verify verdict. verdicts reflect diff content, not PR titles. Part of an automated triage batch.