fix(responses): surface truncated generations as response.incomplete, not completed

[hartmark]

What Problem This Solves

A provider that stopped a generation because it hit the token limit (Chat Completions finish_reason: "length", or a content filter) got translated to the OpenAI Responses API's response.completed event with status: "completed" — indistinguishable from a genuine successful completion. A caller has no signal the output was cut off mid-generation instead of the model actually finishing.

Observed live in production: a model looping on repeated garbled/incoherent text for its entire completion-token budget (completion_tokens: 8192, exactly the cap) got reported as status: "completed" even though the real upstream response carried finish_reason: "length" the whole time.

Why This Change Was Made

The real OpenAI Responses API contract distinguishes this with a dedicated response.incomplete event carrying incomplete_details: { reason: "max_output_tokens" | "content_filter" } — already correctly implemented for the ChatGPT-web bridge (vendor/codex-chatgpt-web/bridge.ts), but the generic Chat-Completions-to-Responses stream translator (translator/response/openai-responses.ts, used by any provider routed through the standard chat-completions path, e.g. Mistral) discarded finish_reason entirely and always emitted status: "completed" regardless of its value.

Fix: remember finish_reason on stream state when it arrives, and in sendCompleted(), map "length"/"content_filter" to status: "incomplete" with the matching incomplete_details, emitting response.incomplete instead of response.completed for those cases. An upstream mid-stream error still takes priority (status: "failed"), and every other finish_reason ("stop", "tool_calls", etc.) keeps the existing completed behavior unchanged — verified by a new sibling test.

Evidence

• Reproduced from a real production log: raw upstream SSE stream chunk shows "finish_reason":"length", but OmniRoute's own aggregated response and the client-facing response.completed event both showed status: "completed".
• New regression test (tests/unit/translator-resp-openai-responses-roundtrip.test.ts): a finish_reason: "length" chunk now produces response.incomplete with incomplete_details: { reason: "max_output_tokens" }, and never response.completed. TDD-verified: fails on the original code (asserts response.completed is undefined, but the original code emits it), passes with the fix.
• Sibling regression test confirms an ordinary finish_reason: "stop" is unaffected (response.completed, status: "completed", no incomplete_details).
• Full tests/unit/translator* + tests/unit/openai-responses* suite (185 tests) green.
• Pre-commit hooks (prettier, eslint, docs-sync, t11 any-budget, tracked-artifacts, ai-attribution) all pass clean.

Production LOC

Net +25 in translator/response/openai-responses.ts (capture finish_reason on state; branch sendCompleted()'s status/event-type/incomplete_details on it). Test file +73/-3.

[diegosouzapw]

Thanks for the clear write-up and the repro. Mapping length/content_filter to response.incomplete with incomplete_details matches the Responses API contract, and the new test fails without the change. Before merging, could you (1) add a changelog fragment under changelog.d/fixes/, and (2) look at open-sse/transformer/responsesTransformer.ts (~l.608), which is the other Chat→Responses path and still emits response.completed for a length finish? Tests for content_filter and for an upstream error combined with length would be nice too.

[hartmark]

Thanks for the review — addressed all four points:

1. Changelog fragment added (changelog.d/fixes/responses-length-status-incomplete.md).
2. open-sse/transformer/responsesTransformer.ts — same bug, same fix: captured finish_reason on stream state and branched sendCompleted()'s status/event-type/incomplete_details on it, mirroring translator/response/openai-responses.ts exactly (including comments cross-referencing each other now).
3. content_filter tests added in both files (tests/unit/translator-resp-openai-responses-roundtrip.test.ts and tests/unit/responses-transformer.test.ts).
4. Upstream-error + length test added — exercises the real deferred-completion path (finish_reason:"length" with no usage yet → awaitingTrailingUsage, then a mid-stream error chunk arrives instead of the expected trailing usage chunk) and confirms status:"failed" wins, never incomplete.

Full translator*/openai-responses*/responses-transformer* suite (225 tests) green. All new tests TDD-verified against the pre-fix code where practical.