fix(telegram): stop block streaming from splitting messages when streamMode is off

Summary

• Problem: When streamMode: "off" is set for Telegram, disableBlockStreaming was left as undefined, allowing blockStreamingDefault: "on" to keep block streaming active. Each LLM text content block then became a separate Telegram message, splitting
  messages on newlines.
• Why it matters: Users see fragmented replies (e.g. a two-line answer arrives as two separate messages) even though they explicitly disabled streaming.
• What changed: Added streamMode === "off" to the condition that sets disableBlockStreaming = true, so block streaming is disabled when stream mode is off.
• What did NOT change: Behavior when streamMode is "partial" or "block", or when blockStreaming is explicitly set to true/false in account config.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Integrations

Linked Issue/PR

• Closes Bug: Telegram messages split by newlines into multiple messages #17679
• Related Bug: Telegram messages appear as edited instead of new when streamMode is partial/block #17668

User-visible / Behavior Changes

Telegram replies are no longer split into multiple messages when streamMode: "off" is configured. Messages with newlines are now delivered as a single message.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22
• Integration/channel: Telegram
• Relevant config: streamMode: "off", default blockStreamingDefault

Steps

1. Configure a Telegram account with streamMode: "off"
2. Send a prompt that produces a multi-line response
3. Observe message delivery

Expected

• Single Telegram message containing all lines

Actual

• Each text content block sent as a separate message

Evidence

• Failing test/log before + passing after

All 5 tests pass in bot-message-dispatch.test.ts, including the new test "disables block streaming when streamMode is off".

Human Verification (required)

• Verified scenarios: streamMode: "off" now sets disableBlockStreaming: true; existing tests for draft streaming and explicit blockStreaming: true config still pass.
• Edge cases checked: blockStreaming explicitly set to true still overrides; streamMode: "partial" behavior unchanged.
• What you did not verify: Live Telegram end-to-end test.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert the single condition change in bot-message-dispatch.ts line 172, or set blockStreaming: true in account config.
• Files/config to restore: src/telegram/bot-message-dispatch.ts
• Known bad symptoms reviewers should watch for: Messages unexpectedly consolidated when block streaming was intentionally desired with streamMode: "off".

Risks and Mitigations

None — the change only adds an additional condition to an existing ternary, scoped to streamMode === "off".

Test plan

• pnpm build passes
• pnpm test passes (5/5 in bot-message-dispatch.test.ts)
• New test covers streamMode: "off" → disableBlockStreaming: true

AI-assisted (Claude). Tested with automation. I understand what the code does.

Greptile Summary

Fixes a bug where Telegram replies were split into multiple messages when streamMode: "off" was configured. Previously, when streamMode was "off", draftStream was undefined, causing disableBlockStreaming to also be undefined. This allowed the blockStreamingDefault: "on" agent config to re-enable block streaming in get-reply-directives.ts, which sent each LLM text content block as a separate Telegram message.

• Adds streamMode === "off" to the condition computing disableBlockStreaming in bot-message-dispatch.ts, so it evaluates to true when streaming is off
• Adds a new test case verifying that streamMode: "off" correctly sets disableBlockStreaming: true and skips draft stream creation
• Updates the test helper dispatchWithContext to accept an optional streamMode parameter (defaults to "partial" for backward compatibility)
• No changes to behavior for streamMode: "partial" or "block", or when blockStreaming is explicitly configured

Confidence Score: 5/5

• This PR is safe to merge — it's a minimal, well-tested one-line fix scoped to a single condition.
• The change is a single condition addition (|| streamMode === "off") to an existing ternary expression. The logic is correct: operator precedence is right, the fix precisely addresses the described bug, and it doesn't affect other stream modes or explicit blockStreaming config. The new test covers the exact scenario, and the test helper changes maintain backward compatibility. I verified the downstream consumer (get-reply-directives.ts) to confirm that disableBlockStreaming: true correctly resolves block streaming to "off".
• No files require special attention.

_{Last reviewed commit: db76553}

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}