hotfix(telegram): stream final replies without completion notify

[s-salamatov]

Summary

Hotfix for Telegram edit-in-place streaming after #1099.

When Telegram streaming was enabled but completion notifications were disabled, the final answer was not treated as a streamed final reply. This restores the expected behavior: Telegram can keep editing/streaming the final reply while stream_notify_on_complete = false only suppresses the completion notification.

What was observed

In live Telegram testing with anonymized session details:

• stream_mode = edit_in_place
• stream_notify_on_complete = false
• final response arrived as a non-streamed whole response instead of being edited/streamed
• completion notification was correctly suppressed
• when the answer exceeded Telegram chunk limits, only the first chunk streamed and later chunks were sent at completion, which matched existing chunking behavior and was not part of this fix

Root Cause

The channel streaming layer distinguishes between:

• streams that only consume progress deltas
• streams that also deliver the final reply text

After #1099, Telegram still reported streams_final_replies = false even when edit-in-place streaming was enabled. That made the chat layer treat Telegram as a progress-only stream for final delivery bookkeeping.

The fix changes Telegram's streams_final_replies implementation to follow is_stream_enabled(...), so a Telegram account with streaming enabled is marked as a final-reply stream regardless of whether completion notifications are enabled.

Code Investigation

Relevant paths checked:

• crates/telegram/src/outbound/stream.rs
  • stream_notify_on_complete controls whether Telegram gets a separate completion notification/final send behavior.
  • It should not disable final reply streaming.
  • streams_final_replies now returns the effective stream-enabled state.
• crates/chat/src/agent_loop.rs
  • dispatcher tests document that final-stream workers receive progress, final delta, and completion
  • current main still broadcasts final deltas to active stream workers, while streams_final_replies controls whether the target is considered completed for normal final delivery
• crates/telegram/src/outbound/tests.rs
  • notify-off Telegram config now asserts that streaming remains enabled for progress and final replies

Validation

Passed:

just format-check
bash ./scripts/check-changelog-guard.sh origin/main HEAD
cargo test -p moltis-telegram --lib notify -- --nocapture
cargo test -p moltis-chat --lib agent_loop::tests -- --nocapture
cargo clippy -p moltis-telegram -p moltis-chat --lib -- -D warnings

Also manually validated the deployed hotfix with Telegram settings stream=on, notify=off: the final answer streamed/edited in Telegram and no completion notification was emitted.

[greptile-apps]

Greptile Summary

This hotfix corrects TelegramOutbound::streams_final_replies so it returns the effective streaming-enabled state rather than a hard-coded false. Before the fix, any Telegram account with streaming enabled was incorrectly treated as a progress-only stream by the chat layer, causing the final reply to be delivered outside the stream even when edit-in-place mode was active.

• crates/telegram/src/outbound/stream.rs: One-line fix — streams_final_replies now delegates to is_stream_enabled(account_id) instead of returning false, ensuring Telegram is recognized as a final-reply stream whenever streaming is turned on.
• crates/telegram/src/outbound/tests.rs: Existing test updated to assert the corrected behavior (streams_final_replies = true) with stream_notify_on_complete = false, and renamed to reflect the new intent.
• crates/chat/src/agent_loop.rs: Two new unit tests document and guard the dispatcher's completed_target_keys semantics for both progress-only and final-reply stream workers.

Confidence Score: 5/5

Safe to merge — the change is a single-line correction to a method that previously hardcoded the wrong return value, all three paths (stream on, stream off, notify off) are now covered by tests, and no production logic in the dispatcher was modified.

The fix is minimal and precisely targeted: one line in stream.rs changes a hardcoded false to a delegation to is_stream_enabled, which is the same check already used by receives_progress_deltas. The surrounding tests explicitly cover the notify-off configuration and the dispatcher completion semantics in both the true and false cases. No unguarded paths were introduced.

No files require special attention.

Important Files Changed

Filename	Overview
crates/telegram/src/outbound/stream.rs	Core one-line fix: streams_final_replies now delegates to is_stream_enabled, correctly marking Telegram as a final-reply stream when edit-in-place mode is on.
crates/telegram/src/outbound/tests.rs	Existing test updated to cover the notify-off + streaming-on configuration and assert corrected streams_final_replies = true behavior.
crates/chat/src/agent_loop.rs	Two new dispatcher unit tests added documenting progress-only vs final-reply stream semantics; no changes to production logic in this file.

Sequence Diagram

sequenceDiagram
    participant CL as ChatLayer
    participant D as ChannelStreamDispatcher
    participant TG as TelegramOutbound
    participant W as StreamWorker

    CL->>D: for_session(...)
    D->>TG: is_stream_enabled(account_id)
    TG-->>D: "true (stream_mode != Off)"
    D->>TG: streams_final_replies(account_id)
    Note over TG: BEFORE fix: always false, AFTER fix: is_stream_enabled
    TG-->>D: true (after fix)
    D->>W: spawn(send_stream with rx)
    CL->>D: send_progress_delta(...)
    D->>W: StreamEvent::ProgressDelta
    CL->>D: send_delta(final text)
    D->>W: StreamEvent::Delta
    CL->>D: finish()
    D->>W: StreamEvent::Done
    W-->>D: Ok() - insert key into completed
    CL->>D: completed_target_keys()
    D-->>CL: target_key - skip normal final delivery

Loading

_{Reviews (1): Last reviewed commit: "fix(telegram): stream final replies with..." | Re-trigger Greptile}