Summary

Fix for Telegram streaming with extended thinking models overwriting previous messages. Execution error will also ovrrerwritng normal message. Manually tested.
Close: #17935 #17883

Problem

When using extended thinking models (e.g. Claude Opus) with Telegram streaming enabled, text output after a thinking block overwrites the previous message instead of creating a new one.

An alternative solution is to provide an option for user to decide, some app like chatGPT or gemini, only shows think process before reply.

Root Cause

The draft stream kept editing the same message because streamMessageId was never reset after a streaming buffer reset. This reset happens when the new partial text is not a continuation of the previous text (e.g., after a thinking block ends).

Fix

1. Add forceNewMessage() method to TelegramDraftStream that resets internal state (streamMessageId, lastSentText, pendingText)
2. Call forceNewMessage() in bot-message-dispatch.ts when a streaming buffer reset is detected

Changes

• src/telegram/draft-stream.ts: Add forceNewMessage() method
• src/telegram/bot-message-dispatch.ts: Call forceNewMessage() on buffer reset
• src/telegram/draft-stream.test.ts: Add test case for forceNewMessage()

Testing

• All existing tests pass and new added test cases
• New test verifies that forceNewMessage() causes a new message to be sent

AI usage

• AI finds codes and provide solution, human provide feedback and review implementation
• TDD by adding test case before writing code

Greptile Summary

This PR fixes Telegram streaming with extended thinking models by forcing a new message when a streaming buffer reset is detected (e.g., after a thinking block ends). Previously, the draft stream kept editing the same message because streamMessageId was never cleared on buffer reset.

• Adds forceNewMessage() to TelegramDraftStream that resets streamMessageId, lastSentText, and pendingText
• Calls forceNewMessage() in the buffer reset branch of updateDraftFromPartial in bot-message-dispatch.ts
• Includes a test verifying that forceNewMessage() causes a new sendMessage call instead of editing the existing message
• The fix is minimal, well-targeted, and correctly placed in the streaming pipeline

Confidence Score: 4/5

• This PR is safe to merge with minimal risk — it's a focused bug fix with correct logic and test coverage.
• The fix correctly addresses the root cause (streamMessageId not being reset on buffer reset). The changes are minimal and well-scoped. One minor robustness concern: forceNewMessage() doesn't reset the stopped flag, which could prevent streaming from resuming in edge cases where the stream was previously stopped. This is unlikely to cause issues in the primary thinking-block scenario but is worth addressing for completeness.
• src/telegram/draft-stream.ts — consider whether stopped should also be reset in forceNewMessage().

_{Last reviewed commit: b974057}