Summary

• Problem: Telegram /reasoning stream can split reasoning into a fresh preview after onReasoningEnd, but the dispatcher rotated the reasoning lane with forceNewMessage() before clearing the previous preview id.
• Why it matters: each split reasoning segment could leave an old Telegram reasoning preview behind, so users see multiple stale reasoning messages instead of one live preview that is cleaned up.
• What changed: clear the current reasoning preview before forcing the next split reasoning preview, then reset the lane state and continue with the existing draft stream lifecycle.
• What did NOT change (scope boundary): answer streaming, tool-progress drafts, final answer delivery, and long-preview page retention are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Telegram uses multiple sendMessage previews instead of editMessageText, leaving stale reasoning messages #80862
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: a split Telegram reasoning stream now clears the previous reasoning preview before creating the next preview, so stale reasoning messages are not orphaned.
• Real environment tested: local OpenClaw checkout on macOS, latest upstream/main worktree, Telegram dispatcher/draft-stream source harness. No live Telegram bot token was used.
• Exact steps or command run after this patch:

env OPENCLAW_TEST_HEAVY_CHECK_LOCK_HELD=1 OPENCLAW_VITEST_MAX_WORKERS=1 pnpm --config.manage-package-manager-versions=false test extensions/telegram/src/bot-message-dispatch.test.ts extensions/telegram/src/draft-stream.test.ts

• Evidence after fix:

Test Files  2 passed (2)
Tests  82 passed (82)

• Observed result after fix: the new dispatcher regression drives two reasoning stream segments separated by onReasoningEnd; it verifies the first reasoning preview is cleared before forceNewMessage() and before the second reasoning preview update, while final cleanup still runs afterward.
• What was not tested: live Telegram DM delivery, because this change is isolated to deterministic dispatcher preview lifecycle and no live Telegram credentials were used.
• Before evidence (optional but encouraged): Telegram uses multiple sendMessage previews instead of editMessageText, leaving stale reasoning messages #80862 includes live PM2 logs showing repeated sendMessage reasoning previews with no editMessageText/deleteMessage cleanup.

Root Cause (if applicable)

• Root cause: splitReasoningOnNextStream rotated the reasoning draft with forceNewMessage() and reset lane state, but did not clear the existing reasoning preview first.
• Missing detection / guardrail: coverage existed for ordinary reasoning streaming and draft-stream rotation, but not the multi-segment reasoning path where onReasoningEnd is followed by another reasoning stream before final cleanup.
• Contributing context (if known): ClawSweeper source review on Telegram uses multiple sendMessage previews instead of editMessageText, leaving stale reasoning messages #80862 identified the same orphan path: the previous preview id could be dropped before final cleanup saw it.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
  • extensions/telegram/src/bot-message-dispatch.test.ts
  • extensions/telegram/src/draft-stream.test.ts
• Scenario the test should lock in: when a reasoning stream ends and a later reasoning segment starts, the dispatcher clears the prior reasoning preview before forcing a new message and updating the next preview.
• Why this is the smallest reliable guardrail: it exercises the real Telegram dispatcher callback sequence without needing a live bot account, and draft-stream.test.ts still covers the underlying clear/force-new behavior.
• Existing test that already covers this (if any): ordinary single reasoning stream coverage existed; split reasoning cleanup did not.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Telegram /reasoning stream no longer leaves earlier split reasoning previews behind when another reasoning segment starts before final cleanup.

Diagram (if applicable)

Before:
reasoning A -> onReasoningEnd -> forceNewMessage -> reasoning B -> final cleanup only sees B

After:
reasoning A -> onReasoningEnd -> clear A -> forceNewMessage -> reasoning B -> final cleanup clears B

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local checkout, Node/pnpm repo environment
• Model/provider: N/A
• Integration/channel (if any): Telegram dispatcher/draft-stream source harness
• Relevant config (redacted): Telegram partial streaming with /reasoning stream behavior from Telegram uses multiple sendMessage previews instead of editMessageText, leaving stale reasoning messages #80862

Steps

1. Simulate onReasoningStream("<think>First</think>").
2. Simulate onReasoningEnd().
3. Simulate onReasoningStream("<think>Second</think>").
4. Deliver final answer and let final cleanup run.

Expected

• First reasoning preview is cleared before the dispatcher forces a new preview.
• Second reasoning segment updates the new preview.
• Final cleanup still clears the active reasoning preview.

Actual

• Matches expected.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • env OPENCLAW_TEST_HEAVY_CHECK_LOCK_HELD=1 OPENCLAW_VITEST_MAX_WORKERS=1 pnpm --config.manage-package-manager-versions=false test extensions/telegram/src/bot-message-dispatch.test.ts extensions/telegram/src/draft-stream.test.ts
  • env OPENCLAW_TSGO_HEAVY_CHECK_LOCK_HELD=1 pnpm --config.manage-package-manager-versions=false run tsgo:extensions
  • env OPENCLAW_TSGO_HEAVY_CHECK_LOCK_HELD=1 pnpm --config.manage-package-manager-versions=false run tsgo:extensions:test
  • pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-message-dispatch.test.ts
  • git diff --check
• Edge cases checked: split reasoning segment order, final cleanup after the second segment, existing draft-stream clear/force-new behavior.
• What you did not verify: live Telegram DM delivery.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: clearing a previous reasoning preview earlier could remove an intermediate reasoning view before final answer delivery.
  • Mitigation: this only happens when a new split reasoning segment is about to start; at any time there should be only one live reasoning preview, and final cleanup still clears the active preview.