[sfeng33]

Purpose

Fixes #53255, #58228, #57998. Also covers the finish_reason half of #53363 and #50889.

Chat finish_reason and Responses item status both claimed more than what happened:

• Chat, non-streaming. tool_choice="required" ending with engine stop but zero parsed tool calls returned finish_reason="tool_calls" next to an empty tool_calls array. An auto tool call parsed from a generation cut by max_tokens returned tool_calls instead of length, so a client could not tell a completed turn from one cut mid-arguments. The streaming path already guarded both ([Bugfix][Frontend] Keep length finish_reason for max_tokens-truncated streaming tool calls #46303), so the same request answered differently depending on stream. The /derender chat paths carried two more hand-written copies of the policy, one with the same max_tokens defect.
• Responses, non-harmony. Every ResponseOutputMessage and ResponseFunctionToolCall was hardcoded status="completed", even inside a response whose top-level status is incomplete with incomplete_details.reason = max_output_tokens. The harmony path already did this correctly. In streaming the last response.output_item.done said completed and the stream ended with response.completed instead of the spec's response.incomplete.
• Responses, harmony streaming. The terminal-event code is shared, so a gpt-oss stream whose response status is incomplete now also ends with response.incomplete instead of response.completed.

Relation to open PRs

This PR is a superset of the open partial fixes and makes all four sites share one rule:

• [Bugfix][Frontend] Do not report finish_reason="tool_calls" when no tool call was made #53256 adds and bool(tool_calls) to the required clause only; leaves the length bug and both derender copies.
• [Bugfix][Frontend] Preserve finish_reason=length for truncated tool calls #58286 gates the relabel on engine stop only; leaves the required-with-zero-calls bug, has conflicts.
• [Bugfix] Report finish_reason='length' for tool calls truncated by max_tokens in streaming #47963 (streaming length) is superseded by the merged [Bugfix][Frontend] Keep length finish_reason for max_tokens-truncated streaming tool calls #46303.
• [Bugfix][Frontend] Return tool_calls finish reason from derendered tool calls #47931 adds a fourth copy of the policy to derender; its e2e derender assertion is still useful on top of resolve_finish_reason().
• [Bugfix][Frontend] Fix Responses item status and Harmony event lifecycle #58018 fixes the non-harmony item status the same way (last item incomplete, streaming close_current); this PR covers that part and derives it from the same finish reason the chat rule uses. Its separate Harmony zero-delta lifecycle fix is independent and still stands.
• [Bugfix][Frontend] Emit response.incomplete for truncated Responses streams #45386 adds the response.incomplete terminal event; covered here (same ResponseIncompleteEvent wrapper and background-replay handling).

Test Plan

Live A/B on H200 with Qwen/Qwen3-0.6B, --enable-auto-tool-choice --tool-call-parser hermes --reasoning-parser qwen3 --max-model-len 4096 (plus a second pair of servers with no tool parser), this branch vs merge-base dfc8e0f3e2, 29 + 9 requests (chat non-stream/stream, n=2, Responses non-stream/stream, Anthropic) replayed twice at temperature=0. max_tokens=18 cuts the model right after the closing brace of the tool-call JSON, so a call is parsed but the engine reports length.

Test Result

Unit: 21 finish_reason tests and 130 Responses tests pass; full test_serving_chat.py 195 passed (GPT-OSS fixture errors also occur on main). pre-commit clean including mypy.

Live A/B, only these fields changed; every other response (complete calls, named, streaming chat, plain text, n=2, 400s without a parser) was byte-identical:

Request	before	after
/v1/chat/completions, tool_choice=auto, max_tokens=18 (call parsed, cut)	finish_reason: "tool_calls"	"length"
same, stream=true	"length"	"length" (now consistent)
/v1/responses, max_output_tokens=6 (message cut)	item status: "completed"	"incomplete"
/v1/responses, tool_choice=required, max_output_tokens=18 (call cut)	item "completed"	"incomplete"
same two, stream=true	output_item.done: completed, ends response.completed	incomplete, ends response.incomplete
no-parser server, /v1/responses, max_output_tokens=6	item "completed"	"incomplete"
/v1/messages, auto tool, max_tokens=18	stop_reason: "tool_use"	"max_tokens"
required / named with a complete call	"tool_calls" / "stop"	unchanged

curl -s localhost:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model": "Qwen/Qwen3-0.6B", "temperature": 0, "max_tokens": 18,
  "messages": [{"role": "user", "content": "What'"'"'s the weather in Paris? Use the tool."}],
  "tool_choice": "auto", "chat_template_kwargs": {"enable_thinking": false},
  "tools": [{"type": "function", "function": {"name": "get_weather",
    "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}}]}'

curl -s localhost:8000/v1/responses -H 'Content-Type: application/json' -d '{
  "model": "Qwen/Qwen3-0.6B", "temperature": 0, "max_output_tokens": 6,
  "input": "Write a long paragraph about the sea.", "chat_template_kwargs": {"enable_thinking": false}}'

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[hickeyma]

Thanks @sfeng33, this looks good. Having one resolve_finish_reason() for chat and both /derender paths is what I was hoping for. Its good that the returning length for a cut auto tool call matches streaming chat and the Rust frontend.

A few small things, none blocking but good to get them in if possible:

1. If the cut lands in reasoning, non-streaming leaves the reasoning item with status=None but streaming marks it incomplete through emit_simple_reasoning_done. Harmony doesn't set a status on reasoning, so I'd drop it from the streaming done event.
2. With parallel_tool_calls=false, the filter runs before build_response_output_items. So for [complete, cut], the complete call is the one that gets marked incomplete. It's rare and fine to leave but maybe add a comment.
3. Harmony streams now end with response.incomplete too because the terminal event code is shared. That's correct but it's worth a line in the description.
4. Tests:
   • Could you add one for background replay stopping on response.incomplete?
   • The batch derender test would fit better in test_derender_stream.py using the existing parsed_derenderer fixture, instead of bare MagicMocks in test_derender.py
   • An expect_tool_calls column in the parametrize would read better than working the expectation out from the input text

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @sfeng33.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[hickeyma]

@chaunceyjiang Do you mind taking a look when you get a chance?

[hickeyma]

@sfeng33 Do you mind pushing this along as it will unblock a lot of issues?

[chaunceyjiang]

/cc @sfeng33 could you resolve the merge conflicts ?

[sfeng33]

Thanks @hickeyma, I merged main.

1. Kept. Streaming used to say completed for a cut reasoning item, and incomplete is the true status. The None in non-streaming was there before this PR.
2. Rare, and the response is incomplete anyway, so I left it.
3. Added to the description.
4. Added the background replay test. I skipped the two style changes.

[chaunceyjiang]

Thanks~

[chaunceyjiang]

/ci run

[github-actions]

✅ Triggered Buildkite CI #95074 for commit 88aa27a600de.

[hickeyma]

Thanks @sfeng33, LGTM.

On point 1, I agree incomplete is the right status for a reasoning item that got cut. My concern is that non-streaming still returns status=None for the same request. A generation cut inside reasoning comes back incomplete when streamed and None
otherwise which is the stream vs non-stream mismatch this PR is fixing elsewhere. It also matters for continuation. should_continue_final_message treats an incomplete reasoning item as something to continue, so the next turn behaves differently depending on which path made the item.

Rather than dropping it from streaming, could non-streaming set it too when reasoning is the last item? In build_response_output_items:

status=last_item_status if not content and not tool_calls else None

That keeps your semantics and makes both paths agree. Happy for it to be a follow-up.