[BugFix] Omit empty tool_calls from OpenAI chat responses

[QwertyJack]

Fixes #44104.

What this PR does / why we need it

This PR omits empty tool_calls arrays from serialized OpenAI chat completion responses:

• non-stream message.tool_calls == []
• stream delta.tool_calls == []

Non-empty tool calls are preserved unchanged.

This fixes an OpenAI API compatibility issue where final assistant responses after a tool result can contain normal text with finish_reason="stop", but still serialize tool_calls: []. OpenAI SDK clients then see message.tool_calls is not None, enter the tool-call path, and fail when indexing the empty list.

Does this PR introduce any user-facing change?

Yes. OpenAI-compatible chat completion responses no longer include empty tool_calls arrays. This aligns the response shape with the absence of tool calls while preserving non-empty tool-call payloads.

Duplicate-work check

• gh issue view 44104 --repo vllm-project/vllm --comments
• gh pr list --repo vllm-project/vllm --state open --search "44104 in:body"
• gh pr list --repo vllm-project/vllm --state open --search "empty tool_calls OpenAI chat responses"

Result: #44105 is the only open PR directly addressing #44104 / empty tool_calls response serialization. Broader keyword hits are unrelated parser/model changes.

How was this patch tested?

• PYTHONPATH=. .venv/bin/python -m pytest -q tests/entrypoints/openai/test_tool_choice_content_none.py
• uv run --with ruff --no-project ruff check vllm/entrypoints/openai/chat_completion/protocol.py vllm/entrypoints/openai/engine/protocol.py tests/entrypoints/openai/test_tool_choice_content_none.py tests/entrypoints/openai/chat_completion/test_completion_with_function_calling.py tests/entrypoints/openai/chat_completion/test_serving_chat.py

Results:

• pytest: 6 passed
• ruff: passed

AI assistance

AI assistance was used to investigate the CI failure, add the serializer guard for unset default tool_calls, and align affected OpenAI SDK integration test expectations with omitted empty tool_calls. The human submitter should review every changed line and the final CI result.

[hclsys]

nice — mirrors the existing ChatCompletionToolsParam._serialize shape at protocol.py:166. one note: this changes the dict shape for any in-process consumer that previously read message["tool_calls"] expecting [] (callbacks, loggers, etc.) — they'd now hit KeyError. probably fine since the public surface is JSON over the wire, but worth a quick git grep for \.tool_calls\b consumers inside vllm just to be safe.

[QwertyJack]

Thanks, checked this.

Commands run:

git grep -n '\.tool_calls\b' -- vllm
git grep -n '\["tool_calls"\]' -- vllm
rg -n 'model_dump\(|model_dump_json\(' vllm/entrypoints/openai vllm/entrypoints/anthropic

Findings:

• The .tool_calls production hits are object/attribute consumers (choice.message.tool_calls, delta_message.tool_calls, parser results, etc.) before serialization. Those still see the model field as []; the serializer only changes the dumped payload.
• Direct message["tool_calls"] production hits are request/conversation message transforms, mostly guarded by message.get("tool_calls") or a prior presence check. I did not find a production path that calls model_dump() on ChatMessage/DeltaMessage and then directly indexes payload["tool_calls"] expecting an empty list.
• The OpenAI chat response model_dump() / model_dump_json() call sites are the outbound API paths. The Harmony conversion paths that dump Pydantic messages use .get("tool_calls", []), so omitted empty fields are handled.

So I think the current shape is safe for in-process vLLM consumers while fixing the over-the-wire OpenAI-compatible payload.

[mergify]

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

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

[chaunceyjiang]

LGTM