Summary

What problem does this PR solve?

• Long Telegram replies (>4096 chars) duplicate the entire preview content as a final emit pass in partial and block streaming modes. The user sees the same reply rendered twice.

Why does this matter now?

• Labelled regression / P1 / impact:message-loss. The bug deterministically corrupts every long Telegram reply in the documented-default streaming.mode: "partial" and in "block"; only "progress" is clean.

What is the intended outcome?

• The lane finalizer treats the preview as covering its delivered prefix even when that prefix ends below the lane chunker's first-chunk boundary, so retained overflow preview pages stay visible and only the missing suffix is emitted.

What is intentionally out of scope?

• No change to draft-stream overflow chaining behavior, dispatcher-side chunking, or progress mode.

What does success look like?

• partial mode: a >4096-char reply lands in ceil(reply_length / textChunkLimit) Telegram messages instead of roughly twice that.
• block mode: the first chunk shown as a preview is reused as final chunk 0 instead of being re-sent alongside chunks 1..N.
• progress mode: unchanged.

What should reviewers focus on?

• extensions/telegram/src/lane-delivery-text-deliverer.ts:405: the relaxed prefix-detection check now also covers deliveredStreamTextAfterStop.length <= firstChunk.length as long as the delivered text is a real prefix of finalText.

Linked context

Which issue does this close?

Closes #87624

Which issues, PRs, or discussions are related?

Related #84885 (adjacent retained-preview cluster, per ClawSweeper review on #87624).

Was this requested by a maintainer or owner?

ClawSweeper review on #87624 marked it clawsweeper:source-repro + clawsweeper:queueable-fix + clawsweeper:fix-shape-clear and pointed at this exact handoff path.

Real behavior proof (required for external PRs)

• Behavior addressed: extensions/telegram/src/lane-delivery-text-deliverer.ts:405 rejected the after-stop prefix unless deliveredText.length > firstChunk.length, so when the draft preview ended on a tighter boundary (HTML rendering caps the preview, or stop() failed before the firstChunk update lands) the finalizer fell through to params.sendPayload(applyTextToPayload(payload, text)) — sending the full final text again — while the preview / retained overflow pages stayed visible.
• Real environment tested: macOS Darwin 25.5.0, Node 22, pnpm 11.2.2; this PR ran the targeted vitest suites locally inside the repo worktree. Live Telegram polling was not exercised against a real bot account in this run.
• Exact steps or command run after this patch:
  • pnpm install --frozen-lockfile
  • node scripts/run-vitest.mjs extensions/telegram/src/lane-delivery.test.ts extensions/telegram/src/draft-stream.test.ts extensions/telegram/src/bot-message-dispatch.test.ts
  • node scripts/run-vitest.mjs extensions/telegram (full plugin suite)
  • Confirmed regression by temporarily restoring the length > firstChunk guard: the new test hands off from a shorter streamed prefix when stop ends below the first chunk boundary failed with expected 'sent' to be 'preview-finalized' (lane fell through to sendPayload(finalText) and clearDraftLane).
• Evidence after fix (terminal capture):

  RUN  v4.1.7 /Users/cornna/project/openclaw_work/wt-87624
  Test Files  123 passed (123)
       Tests  1919 passed (1919)
  

• Observed result after fix: With the relaxed check, the new tests pass and existing 1919 telegram tests stay green. The lane finalizer routes through finalizeDeliveredPrefix(deliveredStreamTextAfterStop, messageId) for any prefix snapshot, so the preview / retained pages remain the active delivery and only the missing suffix is sent via params.sendPayload(followUpPayload(...)).
• What was not tested: Live Telegram Bot API polling against a real bot with streaming.mode: "partial" + textChunkLimit: 3800 and a >6000-char prompt. The fix path is exercised by unit tests but a live roundtrip is recommended before landing — cited under clawsweeper:source-repro.
• Proof limitations or environment constraints: This worktree is a non-maintainer fork checkout; no Crabbox / Testbox access from here. The proof above is source-level + vitest, in line with the clawsweeper:source-repro label on [Bug]: Telegram streaming.mode: "partial" and "block" duplicate the full preview when reply >4096 chars #87624.

Tests and validation

Which commands did you run?

• pnpm install --frozen-lockfile
• node scripts/run-vitest.mjs extensions/telegram/src/lane-delivery.test.ts extensions/telegram/src/draft-stream.test.ts extensions/telegram/src/bot-message-dispatch.test.ts → 161 tests passed
• node scripts/run-vitest.mjs extensions/telegram → 1919 tests passed
• pnpm format:check extensions/telegram/src/lane-delivery-text-deliverer.ts extensions/telegram/src/lane-delivery.test.ts → clean
• node scripts/run-oxlint.mjs extensions/telegram/src/lane-delivery-text-deliverer.ts extensions/telegram/src/lane-delivery.test.ts → exit 0
• pnpm tsgo --noEmit -p extensions/telegram/tsconfig.json → clean

What regression coverage was added or updated?

• extensions/telegram/src/lane-delivery.test.ts: does not duplicate the first chunk when block mode finalizes a long reply covers the block-mode variant (preview shows first chunk, final must reuse it for chunk 0 and only emit chunks 1..N).
• extensions/telegram/src/lane-delivery.test.ts: hands off from a shorter streamed prefix when stop ends below the first chunk boundary covers the partial-mode variant where the preview's lastDeliveredText is a real prefix shorter than firstChunk — the failure mode that caused the dispatcher to fall through to sendPayload(finalText) and duplicate retained pages.

What failed before this fix, if known?

• With the prior length > firstChunk guard restored, the new hands off from a shorter streamed prefix... test failed at expectPreviewFinalized with expected 'sent' to be 'preview-finalized' — i.e., the lane fell through to fullText delivery instead of finalizing in place.

If no test was added, why not?

• N/A. Added regression tests for both partial and block surface shapes called out in the issue.

Risk checklist

Did user-visible behavior change? (Yes)

• Telegram message counts for long streamed replies in partial/block mode change from "preview + full duplicated final pass" to "preview + suffix only". This is the bug fix and matches the documented behavior already shipped for progress mode.

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

• No config keys touched; no doctor migration.

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

What is the highest-risk area?

• The relaxed prefix check now triggers finalizeDeliveredPrefix even when the delivered preview is shorter than firstChunk. If stream.lastDeliveredText ever returned a non-prefix prefix-like string (e.g., the stream had been reset to fresh state with stale content), we already bail out via the isDeliveredPrefix guard. The new branch only fires when finalText.startsWith(deliveredText) is true, so it cannot leak unrelated content.

How is that risk mitigated?

• Two regression tests, plus the existing 32 lane-delivery tests covering longer-prefix, equal-firstChunk, no-prefix, no-stream, oversized buttons, voice-fallback, and reasoning-lane shapes all stay green.

Current review state

What is the next action?

• Maintainer review and (if required) live Telegram proof per clawsweeper:source-repro before landing.

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

• Live Telegram roundtrip from a maintainer environment to confirm the visible message-count change matches the unit-test trace.

Which bot or reviewer comments were addressed?

• ClawSweeper review at [Bug]: Telegram streaming.mode: "partial" and "block" duplicate the full preview when reply >4096 chars #87624 (comment): applied the suggested Best possible solution — fix in the existing Telegram draft/lane delivery path, with partial and block regression tests; live Telegram proof is the remaining gap called out under Proof limitations.