fix(ai): absorb content after the finish reason - #49167

Pulled your branch (16b4038) and ran the two affected suites here: 40 pass, 0 fail, including the three new cases. Accumulating toolCallEvents / completedTools instead of replacing them is the right call once a late frame can finalize more than once.

One shape the new tests don't cover, and it now degrades into a silently wrong result instead of a loud error:

Dropping the state.finishReason === undefined gate at openai-chat.ts:1082 makes finished recompute on every post-finish frame, and ToolStream.finishAll clears the tool map (tool-stream.ts:237). So a late call is finalized on the very first frame that carries its id/name. If the provider splits that late call across frames — identity first, arguments after — the arguments aren't there yet:

delta({content:"Hello"}) / delta({}, "stop")
delta({tool_calls:[{index:0,id:"call_1",function:{name:"lookup",arguments:'{"city":'}}]})
delta({tool_calls:[{index:0,function:{arguments:'"Paris"}'}}]})

Ran exactly that against your head: the response comes back as toolCalls: [{id:"call_1",name:"lookup",input:{}}]. The continuation chunk lands in pendingTools, and the missing-identity check at openai-chat.ts:1068 is skipped once state.finishReason is set, so it vanishes without a trace. Before this PR the same stream failed loudly; now it dispatches a tool call with empty input. Your "finishes a tool call absorbed after a terminal chunk" test can't catch it because the single late chunk already carries arguments:"{}".

finishAll is already reachable from finishEvents (openai-chat.ts:1118-1121), so would it be simpler to finalize late calls there — relax that guard to Object.keys(state.tools).length > 0 — and leave the per-frame path in step as it was? Late calls then finish once, at end of stream, with all argument deltas accumulated, and the split case above becomes a good test to pin it.

The same stream on Mistral is dropped rather than finalized: finished at mistral-chat.ts:693 only runs on a frame that carries finish_reason, and Mistral's finishEvents never converts state.tools, so a late tool call with complete arguments comes back as toolCalls: [] (also verified on your head). So "a tool call that arrives late gets finalized" holds for OpenAI Chat but not for Mistral — either fix both or narrow that part of the description.

Minor: hasLateContent still lets text and reasoning through after length / content_filter while late tools are dropped for incomplete finishes. Intentional? A late text chunk after content_filter ends up in response.text.

Verdict: commented — one fix I'd ask for before merge (the Mistral parity gap below); everything else here is solid and well-tested.

Overall Assessment

The direction is right. #43040 is a real failure — the strict guard from #40798 discarded an entire step over one trailing chunk — and matching the AI SDK / LiteLLM / official-SDK pass-through behavior is the correct compatibility trade. The terminal-finish_reason requirement still guards stream completeness, and late chunks now land in the output they belong to.

The rework after holny's review is also right, and I verified the net diff removes his reproducer's failure: per-frame finishAll in openai-chat.ts is back behind state.finishReason === undefined (1083-1087), late deltas accumulate in tools/pendingTools, and finishEvents finalizes them once with complete arguments (1122-1132). The length / content-filter drop for unconfirmed tools is preserved on both parsers, and the new [...completedTools, ...finished.events] accumulations are consistent with finalization paths that can no longer repeat on OpenAI. The added tests pin the split-args case directly on both protocols.

One structural tradeoff worth recording, not blocking: absorbing trailing chunks unconditionally means provider misbehavior such as a duplicated trailing chunk is now tolerated instead of surfaced. That is the deliberate price of compatibility, the inline comments document the rationale well, and I don't think it needs more.

What keeps this from a clean pass is the one miss below: it's the same failure class that was just fixed on the sibling parser, and it's introduced by this PR's absorption change rather than pre-existing (no post-finish frame could reach finished on Mistral before).

🟠 Major

• packages/ai/src/protocols/mistral-chat.ts:692-695 — finished is missing the first-terminal state.finishReason === undefined gate; a repeated terminal chunk with trailing content can finalize accumulated late tool calls early with partial arguments, and the continuation deltas are then silently dropped. (inline)

🟡 Minor

• packages/ai/test/provider/openai-compatible-chat.test.ts:578-634 — malformed late tool deltas (dropped, not fatal) and late reasoning absorption are untested; both are cheap fixtures. (inline)
• packages/ai/test/provider/mistral-chat.test.ts:645-679 — the late-content assertion is folded into an unrelated test; split it so failures attribute cleanly. (inline)

🔵 Info

• PR description drift: item 2 still describes the pre-96131f7 behavior (late call "finalized in the same frame"); the head finalizes once at stream end. "Three new tests" is now five new plus two updated. A quick body refresh would keep the description matching what reviewers are approving.
• Verification boundary: the Mistral sequence above is a static trace — I couldn't execute bun test in this environment, so the author's and holny's suite runs remain the execution evidence. Confirming the traced case with a test would close both that and the coverage ask.

Review Warnings

• Could not run bun test / bun typecheck (command profile in this sandbox); all verification here is by reading the head source and tracing the parser state machine against the new tests.

Questions for the Author

• Was omitting state.finishReason === undefined from Mistral's finished deliberate, or an oversight? If repeated-terminal frames are considered out of scope, a one-line comment saying so (like the others you added) is enough for me.

cc @marwanvx

Posted as a COMMENT review (non-collaborator account — REQUEST_CHANGES isn't available); the ask above stands on its own.
This review was generated by an AI assistant.