Summary

What problem does this PR solve?
In Telegram, channels.telegram.streaming.mode: "partial" and "block" modes duplicated the entire stream preview content on final emit if the reply size exceeded the ~4096 characters per-message cap. When the message was block-rotated into a new message, the draft stream controller unknowingly replayed chunks that were already delivered in preceding block/partial transmissions because it received the full cumulative text for final emit processing.

Why does this matter now?
This created broken and frustrating user experiences where long responses on Telegram were sent twice, interrupting reading flow and visually inflating output length.

What is the intended outcome?
The final stream text delivery respects the current activeChunkIndex tracked across stream rotations. The system now accurately targets the current active preview chunk for inline finalization and accurately distributes the remainder of the payload downstream sequentially. Additionally, partial streaming skips redundant text-only block deliveries that were needlessly stepping over incremental partial streaming.

What is intentionally out of scope?
Refactoring the larger core outbound block delivery protocol is out of scope. This addresses the Telegram-specific lane-delivery module interface handling.

What does success look like?
Long Telegram responses (>4096 characters) seamlessly transition to multiple paginated messages without repeating the initial content.

What should reviewers focus on?

• Verification that lane.activeChunkIndex is scoped securely to onSupersededPreview so it only increments for retained overflow chunks.
• Re-checking bounds clamp logic so active chunks perfectly index valid active streams.
• Reviewing isDeliveredPrefix and suffix handling changes, ensuring they use activeFullText rather than text.

Linked context

Which issue does this close?

Closes #87624

Which issues, PRs, or discussions are related?

Related #84885

Was this requested by a maintainer or owner?

Yes.

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Final emit duplicating messages for Telegram single-turn replies exceeding the per-message chunk limit.
• Real environment tested: Live Telegram Bot API via GitHub Codespaces running pnpm gateway:dev (using OpenRouter/GLM for generation).
• Exact steps or command run after this patch:
  1. Set Telegram config to streaming.mode: "partial", chunkMode: "length", and artificially lowered textChunkLimit: 15 to force the chunking behavior on a short prompt.
  2. Sent the bot the prompt: "What is the capital of France?"
• Evidence after fix: See the screenshot at the top of this PR.
• Observed result after fix: The reply cleanly split into 3 small chunks (due to the 15-char limit) and successfully finalized in place without duplicating the first chunks at the end of the generation.
• What was not tested: Exhaustive combinations of all available bot presentation controls (buttons/media) crossing the chunk boundary.
• Proof limitations or environment constraints: Tested using an artificially low chunk limit (15) to efficiently simulate the 4096-character overflow behavior on a live connection.
• Before evidence: Without the fix, this exact 15-char limit configuration would result in the first chunks printing again at the very bottom of the chat.

Tests and validation

Which commands did you run?
pnpm test:extensions & pnpm test:unit

What regression coverage was added or updated?
Coverage checks updated inside lane-delivery.test.ts and bot-message-dispatch.test.ts to properly account for the internal track increment value activeChunkIndex. Additional regressions created targeting long finals post-rotation.

What failed before this fix, if known?
The final delivery loops assumed message sequences weren't rotated locally by previous block triggers inside deliverLaneText. Text-only blocks would also get silently dropped if streams weren't properly enabled.

If no test was added, why not?
Tests were successfully added.

Risk checklist

Did user-visible behavior change? (Yes/No)
Yes (duplicate spam was removed)

Did config, environment, or migration behavior change? (Yes/No)
No

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)
No

What is the highest-risk area?
Draft lane text rotation bounds targeting potentially non-existent sequence indexes.

How is that risk mitigated?
Indices are firmly clamped against 0 and chunks.length - 1 with logical fallbacks handling edge-case length disparities securely.

Current review state

What is the next action?
Maintainer review and functional verification.

What is still waiting on author, maintainer, CI, or external proof?
CI success.

Which bot or reviewer comments were addressed?
Codex recommendation to provide concrete source-backed bounds correction targeting the final delivery overflow chunks. Re-scoped activeChunkIndex increments to onSupersededPreview specifically, ensured it isn't incremented in generic resets, and modified text-block delivery skips so they only suppress when an active partial draft exists.

AI Assistance Transparency

• AI-assisted: This PR was generated with the assistance of an LLM.
• Code Understanding: I have reviewed the logic regarding activeChunkIndex and how it correctly targets the active stream without duplicating already-delivered final chunks. I confirm I understand how this code works.
• Prompts used: I provided the exact GitHub issue text and the codebase context to the LLM.
• Real behavior proof: Attached in the section above. I have personally compiled and run this against a local Telegram bot to verify the duplicate messages are gone.
• Codex Review: N/A (I do not have access to the local codex CLI tool, but I addressed the Codex bot's comments from the issue ticket).

Maintainer update (2026-06-01)

Maintainer repair pushed to this PR branch at 5d9f143b5f7811a1199315d0f84a0fcc1647b1f3.

Additional fixes on top of the contributor patch:

• Recomputes retained long-final chunks after stopping the draft lane so already-visible overflow chunks are not resent.
• Limits partial-mode text-only block suppression to true duplicate answer blocks, preserving tool-progress, button-bearing, and differing block deliveries.
• Finalizes duplicate streamed blocks when no final payload follows, including pending draft streams that materialize their message id only after stop().
• Keeps inline buttons attached to the post-stop active retained chunk instead of editing a stale first chunk.

Maintainer verification:

• node scripts/run-vitest.mjs extensions/telegram/src/lane-delivery.test.ts extensions/telegram/src/bot-message-dispatch.test.ts extensions/telegram/src/draft-stream.test.ts (170 tests)
• node scripts/run-oxlint.mjs extensions/telegram/src/lane-delivery-text-deliverer.ts extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/lane-delivery.test.ts extensions/telegram/src/bot-message-dispatch.test.ts
• git diff --check origin/main...HEAD
• .agents/skills/autoreview/scripts/autoreview --mode branch --base origin/main clean on the repaired branch before the final unrelated main rebase
• L2 tmux proof on pushed head 5d9f143b5f7: L2_TELEGRAM_EXIT=0 vitest=0 lint=0 diff=0
• Testbox-through-Crabbox changed gate: tbx_01kt0wfts5fck0xvqp05zg9erx, lanes extensions, extensionTests, exit 0