Summary

Fixes #42747.

Streaming Chat Completions with tool_choice="none" — or omitted on a no-tools request, where request.tool_choice ends up as None — could still produce delta.tool_calls and finish with finish_reason="tool_calls" whenever the server was launched with a --tool-call-parser and the model output happened to match that parser's tool-call format. Non-streaming Chat Completions already handles both cases correctly.

Root cause

DelegatingParser.parse_delta in vllm/parser/abstract_parser.py invokes _extract_tool_calls_streaming unconditionally once the stream enters the tool-call phase, without inspecting request.tool_choice. The non-streaming path at vllm/entrypoints/openai/chat_completion/serving.py already short-circuits both cases:

elif not request.tool_choice or request.tool_choice == "none":
    message = ChatMessage(role=role, reasoning=reasoning, content=content)

The streaming path was missing the equivalent guard.

Fix

In DelegatingParser.parse_delta, when not request.tool_choice or request.tool_choice == "none", skip _extract_tool_calls_streaming and surface any remaining (post-reasoning) text as plain content. Because the tool parser is never invoked, state.function_name_returned stays untouched and the downstream tools_streamed[i] flag stays False, so finish_reason naturally falls back to "stop". Reasoning extraction is untouched.

Difference from #42752

#42752 was the original attempt at this fix and at the time this PR was opened was OPEN, CONFLICTING with main, last updated 2026-05-23, and only guarded on request.tool_choice == "none". The review feedback on that PR (gemini-code-assist, 2026-05-15) explicitly asked to broaden the check to also cover request.tool_choice is None — the no-tools request case raised by @QwertyJack in the comment thread under #42747.

This PR implements that broader guard so streaming matches the non-streaming not request.tool_choice or request.tool_choice == "none" semantics exactly. Acknowledging @hoobnn for the original direction; happy to close this if #42752 is updated with the same broader guard.

This logic has been independently validated downstream in vllm-project/vllm-ascend#9776 against vLLM v0.20.2.

Duplicate-PR check (per AGENTS.md)

gh issue view 42747 --repo vllm-project/vllm --comments
gh pr list --repo vllm-project/vllm --state open --search "42747 in:body"

• [Bugfix] Honor tool_choice="none" in Chat Completions streaming #42752 (@hoobnn, OPEN, stale 2 weeks at PR-open time, CONFLICTING, pre-commit FAILURE): same approach, narrower guard, awaiting author response to broaden.
• entrypoints/openai: skip tool parser in streaming when tool_choice="none" #42868 (OPEN): unrelated approach — patches chat_completion/serving.py, not abstract_parser.py; touches a different surface area.

This PR is materially different from #42752 in the guard scope.

Test plan

Added in tests/entrypoints/openai/test_tool_choice_content_none.py:

• test_parse_delta_with_tool_choice_none_skips_tool_parser — explicit tool_choice="none": parser is not invoked, raw delta text surfaces as DeltaMessage.content.
• test_parse_delta_with_omitted_tool_choice_skips_tool_parser — omitted tool_choice on a no-tools request (request.tool_choice is None): parser is not invoked, raw delta text surfaces as content. This is the additional case beyond [Bugfix] Honor tool_choice="none" in Chat Completions streaming #42752.
• test_parse_delta_without_tool_choice_none_still_runs_tool_parser — sanity: tool_choice="auto" still hits the tool parser (no regression).
• test_parse_delta_tool_choice_none_multiple_chunks_remain_content — multi-chunk streaming stays in content mode across deltas.

A local pytest run was not possible in the contributing environment (macOS aarch64, no torch available). The new tests rely only on vllm.entrypoints.openai.chat_completion.protocol, vllm.parser.abstract_parser and a stub parser; they will run on CI on this PR.

AI assistance was used (Claude) to draft the patch and the test stub, mirroring the already-reviewed approach in #42752.

Closing note (2026-05-31): @hoobnn has folded the broader guard into #42752 and rebased it onto current main with the same request.tool_choice is None regression coverage. Closing this PR as duplicate of #42752 per its now-equivalent scope. Thanks @hoobnn for picking it up.