[richard-for-bugen]

Overview

Python's chat and completions validate_stream_options check the raw JSON body: if data.get("stream_options") and not data.get("stream"). With streaming off, any stream_options object that has a key is a 400, even when every value is null or the key is one Python does not model; only {} and null pass. vllm-project#62643 made Rust accept {} like Python, but it decides emptiness on the deserialized options, so {"include_usage": null} and {"include_obfuscation": true} (an OpenAI option neither frontend models) count as empty and are accepted.

The OpenAI API agrees with Python on the all-null case: with stream=false, a live probe returns 400 "The 'stream_options' parameter is only allowed when 'stream' is enabled." for {}, {"include_usage": null} and {"include_usage": false}, and 200 for an absent or null stream_options. This PR keeps Python's acceptance of {} and rejects the rest like both.

stream=false and stream_options	Python	Rust before	Rust after
absent or null	200	200	200
{}	200	200	200
{"include_usage": false}	400	400	400
{"include_usage": null}	400	200	400
{"include_obfuscation": true}	400	200	400

/inference/v1/generate is unchanged: Python's generate route has no stream_options check.

Ownership and layering

The rule is about the raw request object, so it is captured where that object is parsed: StreamOptions (the shared HTTP DTO in routes/openai/utils/types.rs) records at deserialization whether the object had any key, and is_empty reports that. The three existing consumers of is_empty (chat validate_request_compat, chat validate_chat_cross_parameters, completions validate_request_compat) are unchanged. The custom Deserialize reads the object into a JSON map once and derives the two typed fields from it, the same shape as the existing ChatMessage deserializer.

Validation

Commands from .buildkite/scripts/run-rust-frontend-cargo-ci.sh (style-clippy and test), run from the repo root with a per-worktree target dir:

cargo fmt --manifest-path rust/Cargo.toml --all -- --check   # ok
cargo sort --workspace --check rust                          # ok
cargo deny --manifest-path rust/Cargo.toml --config rust/deny.toml check bans   # ok
cargo clippy --manifest-path rust/Cargo.toml --workspace --all-targets --all-features --locked -- -D warnings   # ok
cargo nextest run --manifest-path rust/Cargo.toml --workspace --all-features --locked --no-fail-fast
# 2320 tests run: 2320 passed, 13 skipped

• Chat and completions validate_request_compat_rejects_stream_options_without_streaming gain {"include_usage": null} and {"include_obfuscation": true}; the chat test runs the request through both chat checks. Both tests fail with the StreamOptions change reverted.
• validate_request_compat_accepts_empty_stream_options_without_streaming (chat and completions) still pins {}.
• validate_request_compat_accepts_stream_options_with_streaming (chat and completions) pins that the same null and unknown-key objects pass when stream=true.
• Two chat convert tests built StreamOptions as struct literals; they now parse it from JSON, since emptiness is a property of the request object.

Python test pinning the behavior: tests/entrypoints/openai/chat_completion/test_chat.py::test_chat_completion_stream_options (not yet in Rust CI; the file has other open Rust gaps).

A wrongly typed option, such as {"include_usage": "yes"}, still fails body deserialization; the typed fields are parsed by a derived Deserialize from the same map.

Codex review (gpt-6.1-sol, high): approve with nits. It confirmed the gap against the Python request models and a temporary HTTP probe (base returns 200 for stream=false with {"include_usage": null}; all 60 probe combinations across chat, completions, both render routes and generate pass at the head).

• P3, cover the new objects with streaming on, so a deserializer that rejected them outright could not pass: fixed with the accepts_stream_options_with_streaming tests. They parse the whole request from JSON, which is where such a deserializer would fail, so they stay at the validator level instead of the HTTP route tests.

Not a duplicate: no open upstream PR changes this check; vllm-project#61275 adds a new Python option and does not touch the validation.

[BugenZhao]

It’s ugly to distinguish between absent and explicit NULL…