[Bugfix] Fix Qwen3CoderToolParser anyOf/oneOf type resolution for nullable params

[AAISSJ]

Purpose

Fix incorrect type resolution for anyOf/oneOf schemas, type-as-array patterns, and $ref schemas in Qwen3CoderToolParser._convert_param_value.

The previous fix (#36032) hardcoded param_type = "object" for all anyOf schemas. While this solved the double-encoding issue for object-typed anyOf params, it breaks nullable parameters with non-object types — they get routed through json.loads instead of their correct conversion branch (int(), float(), etc.).

This PR also subsumes the $ref handling proposed in #37652, integrated cleanly into the same _resolve_param_type helper.

Root Cause

Pydantic v2 emits anyOf for every Optional[T] field:

count: Optional[int] = 5
# becomes:
{"anyOf": [{"type": "integer"}, {"type": "null"}], "default": 5}

With the #36032 fix, this anyOf is resolved to param_type = "object", so the value "5" goes through json.loads("5") — works by accident for integers, but for strings it would try to parse a plain string as JSON and fail or behave unexpectedly.

Similarly, Pydantic model inputs produce $ref schemas (e.g. {"$ref": "#/$defs/ToolInput"}) with no "type" field, which also fell through to "string".

Fix

Two new helper methods to keep type resolution logic clean and DRY:

_first_non_null_type(type_value) — static method that extracts the first non-null type from either a scalar ("integer") or a type-as-array (["integer", "null"]). Reused in both top-level type resolution and anyOf variant scanning.

_resolve_param_type(param_def) — resolves the effective type string from a parameter definition. Handles four cases:

1. Direct "type" field (including type-as-array)
2. anyOf/oneOf variants (extracts first non-null type from variants)
3. $ref schemas (treated as "object" to trigger json.loads)
4. Fallback to "string"

This replaces the previous inline logic with deeply nested if/elif/else blocks, using early returns for clarity.

Affected Cases

Schema	#36032 ("object")	This PR (actual type)
anyOf[integer, null]	wrong — routes to json.loads	"integer" → int() ✅
anyOf[string, null]	wrong — routes to json.loads	"string" → as-is ✅
anyOf[array, null]	partial — works but semantically wrong	"array" → json.loads ✅
anyOf[object, null]	correct	"object" → json.loads ✅
anyOf[object, object] (#36032 case)	correct	"object" → json.loads ✅
anyOf[string, integer, null]	wrong — routes to json.loads	"string" (first non-null) ✅
{"type": ["integer", "null"]} (top-level)	not handled	"integer" → int() ✅
anyOf[{"type": ["integer", "null"]}] (nested)	not handled	"integer" → int() ✅
{"$ref": "#/$defs/Model"} (#37652 case)	not handled	"object" → json.loads ✅

Also handles oneOf (used by FastAPI and other frameworks) and filters null types expressed as both {"type": "null"} (string) and {"type": null} (Python None, seen in some Pydantic outputs).

Test Plan

Added test_extract_tool_calls_anyof_type_conversion covering 7 patterns:

"anyof_int":       {"anyOf": [{"type": "integer"}, {"type": "null"}]}     → 5 (int) ✅
"anyof_str":       {"anyOf": [{"type": "string"}, {"type": "null"}]}      → "hello" (str) ✅
"anyof_array":     {"anyOf": [{"type": "array"}, {"type": "null"}]}       → ["a","b","c"] (list) ✅
"anyof_obj":       {"anyOf": [{"type": "object"}, {"type": "null"}]}      → {"key":"value"} (dict) ✅
"type_as_array":   {"type": ["integer", "null"]}                          → 42 (int) ✅
"multi_non_null":  {"anyOf": [{"type": "string"}, {"type": "integer"}, {"type": "null"}]}
                                                                          → "some text" (str, first non-null) ✅
"ref_param":       {"$ref": "#/$defs/ToolInput"}                          → {"city":"Paris"} (dict) ✅

Existing test suite passes with no regressions:

tests/tool_parsers/test_qwen3coder_tool_parser.py — 19 passed (+ 1 new = 20 total)
tests/tool_parsers/test_qwen3xml_tool_parser.py — 9 passed, 8 xfailed

Follow-up

Qwen3XMLToolParser._get_param_type has the same issue — it uses properties[param_name].get("type", "string") which falls back to "string" for anyOf schemas. This PR intentionally scopes the fix to Qwen3CoderToolParser only. A follow-up PR for the XML parser will be submitted once this is merged.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

🚀

[gemini-code-assist]

Code Review

This pull request provides a crucial bugfix for tool parameter type resolution in Qwen3CoderToolParser, specifically for anyOf/oneOf schemas representing nullable types. The change correctly extracts the actual non-null type instead of hardcoding it as "object", which resolves issues with non-object nullable parameters. My review identifies a remaining edge case where the new logic does not handle a valid JSON Schema construct where the type field is an array (e.g., {"type": ["integer", "null"]}). I've provided a suggestion to make the type extraction more robust to cover this scenario.

[chaunceyjiang]

LGTM.

Thanks. Could you write an end-to-end test for this?

[AAISSJ]

Hi, @chaunceyjiang

I've added a streaming e2e test (test_extract_tool_calls_anyof_type_conversion_streaming) that exercises the full pipeline: tokenize → incremental decode → extract_tool_calls_streaming with anyOf nullable schemas. Both non-streaming and streaming paths now have coverage for type resolution.

Update: Also added $ref coverage to the streaming e2e test — the filters parameter uses {"$ref": "#/$defs/SearchFilters"} to verify that $ref schemas are correctly resolved to "object" in the streaming pipeline.

Please let me know if there's anything else you'd like me to address.

• streaming e2e test commit: 4e076bd
• $ref streaming coverage commit: 22cdf04

[schoennenbeck]

I'd be in favor of using this more comprehensive PR instead of mine (#37652).

[chaunceyjiang]

Thanks~ @schoennenbeck @AAISSJ

Please fix the pre-commit errors.

[AAISSJ]

Thanks~ @schoennenbeck @AAISSJ

Please fix the pre-commit errors.

Thanks, @chaunceyjiang @schoennenbeck
Could you add the ready label so pre-commit CI can run? The linting fix is in the latest commit (d552b46).

[AAISSJ]

Hi, @chaunceyjiang
Can you approve this PR ?

[schoennenbeck]

@chaunceyjiang Would be great to get this merged before the next release. Qwen3.5-family are some of the most capable free models and currently in vllm they are incompatible with up to date versions of pydantic-ai.

[chaunceyjiang]

thanks

[ProExpertProg]

This PR broke "Async Engine, Inputs, Utils, Worker, Config (CPU)" in CI, proof:

• this commit: https://buildkite.com/vllm/ci/builds/59231/steps/canvas?sid=019d48ff-d70a-4d21-813e-2504db972ce0&tab=output
• previous commit: https://buildkite.com/vllm/ci/builds/59225/steps/canvas?sid=019d48a3-c247-4883-8e2c-e2d64a83e1f9&tab=output

[schoennenbeck]

@AAISSJ I can tackle this. But since this is your PR I thought I'd ask first.

[bbrowning]

It looks like we had an ordering issue between #38189 and this one. CI didn't catch this because nothing forced CI to re-run between when 38189 merged and when this merged, so this one had stale valid CI checks making it look good to merge.