flush_intermediates bypasses the deliverability gate, so intermediates ship unconditionally

[adolfousier]

Symptom

An audit reply arrived twice, two minutes apart: once at 16:49 as a numbered list, once at 16:50 as the same content in a table. Same meaning, different formatting, two separate Telegram messages.

Log for the turn:

16:50:27 Telegram: agent call completed — delivering final response
16:50:27 Telegram dedup: response.content len=976, sent_intermediates count=1

sent_intermediates count=1 proves an intermediate was sent as its own message. The final response was the 16:50 table; the 16:49 list was the intermediate.

Cause

There are TWO paths that deliver intermediates, and only one is gated.

Streaming loop (handler.rs) checks is_deliverable_rich_report before promoting an intermediate to its own message — the #582 rule that it must carry a table and clear a length floor.

flush_intermediates (intermediates.rs:17) sends every queued intermediate unconditionally. No classifier check anywhere in it. It pushes each one to sent_intermediates, which is the counter above.

Its own doc says it is "called from resume + follow-up paths", and follow_up_question.rs:117 is one caller. So any turn passing through those surfaces dumps its intermediates verbatim, table or not.

So "intermediates only surface when they carry a table" was only ever true for one of the two ways they reach a chat.

Why it was missed

A revert of the streaming classifier (64edc85d) was expected to stop this and did not, because it addressed the gated path. The binary was rebuilt and the duplicate persisted, which is what exposed the second path.

Worth recording: the conclusion "the streaming classifier promoted it" was drawn from sent_intermediates count=1 without first checking WHICH code path increments that counter. Both do.

Fix

Apply the same deliverability decision in flush_intermediates that the streaming path applies, so both agree on what earns its own message. An intermediate that does not qualify should fold rather than send.

Care

• The dedup in delivery.rs will not save this. It strips a final response that overlaps a sent intermediate, but compares normalized TEXT — a bullet list and a table carrying the same meaning share almost no bytes, so nothing is stripped.
• flush_intermediates runs where no user message is in scope (resume, follow-up), so anything it gains must not assume a live turn.
• Whatever gate is used must be shared rather than duplicated, or the two paths will drift again exactly as they did here.

[adolfousier]

Fixed in 1bc58dbf.

flush_intermediates now calls is_deliverable_rich_report before sending, so both delivery paths apply the same rule. It calls the shared function rather than restating the rule, which is the point — restating it is how the two drifted apart in the first place.

Verified both paths reference the gate. Full suite 5631 passing, clippy clean.

Why this took two attempts, recorded

Reverting the streaming classifier (64edc85d) was expected to stop the duplicate. The binary was rebuilt and it persisted, which is what exposed the second path.

The reasoning error worth naming: sent_intermediates count=1 was read as proof the STREAMING classifier had promoted the message, without first checking which code path increments that counter. Both do. The owner's objection — that the running binary already contained the revert — was correct, and the evidence I had did not distinguish the two paths.

Related limitation, unchanged

The dedup in delivery.rs cannot catch this class. It strips a final response that overlaps a sent intermediate by comparing normalized TEXT, and a bullet list versus a table carrying the same meaning share almost no bytes. That is why the duplicate survived dedup and why gating at send time is the right layer.