GitHub Repo
vLLM Community Reports Structured Output Bug That Can Rewrite JSON Constants Under Certain Settings
Under certain settings, the Guidance backend rewrites constant objects, causing valid outputs to be rejected and invalid variants to pass. The community has submitted a fix and tests, but the change has not been merged, and the affected version range remains unclear.

On September 25, the vLLM community reported a structured output bug: when using the Guidance backend with the option to disallow additional properties enabled, preprocessing may rewrite constant object values in a schema. The reporter provided a reproduction that requires neither model weights nor a GPU. A fix proposed the same day is still under review. [Bug report](https://github.com/vllm-project/vllm/issues/58695), [proposed fix](https://github.com/vllm-project/vllm/pull/58709).
The trigger is setting `disable_additional_properties` to `true`. The official documentation says this option is disabled by default and applies only to Guidance. Under the JSON Schema specification, `const` requires data to equal a specified value, while `enum` requires data to match one of the listed values; these values can be complete objects, whose internal fields should not be treated as another layer of validation rules. Fields inside a constant object must remain unchanged, even if their names match validation keywords. From this rule, we can infer that if preprocessing changes the data, constrained decoding cannot guarantee compliance with the caller's original specification, even when it follows the compiled result. [Configuration documentation](https://docs.vllm.ai/en/latest/api/vllm/config/structured_outputs/), [validation specification](https://json-schema.org/draft/2020-12/json-schema-validation).
The report says that, on the tested main branch, the processing function traverses all dictionaries and arrays and may add a field disallowing additional properties when it encounters `properties` or `patternProperties`. The case uses a GeoJSON object containing property data. As a result, the matcher rejects a constant value that was originally valid, while allowing an invalid variant with extra fields. The issue occurs before the schema is passed to llguidance for compilation; a control case without the fields mentioned above was not rewritten. [Reproduction results](https://github.com/vllm-project/vllm/issues/58695).
The proposed fix instead recurses only through keywords that contain subschemas, preserving constant values, enum values, default values, and example data. It also avoids contaminating the field-name mapping. The author reports seven local tests passing and two not selected, but as of the September 26 check, the change had not been merged and should not be treated as a fix in an official release. [Fix and test record](https://github.com/vllm-project/vllm/pull/58709).
As an engineering implication, this could create a validation gap between the generation and application layers for data extraction or agent tool parameters that use constrained decoding. Teams can validate outputs separately against the original schema and add constant objects with reserved-word fields to regression tests. If temporarily disabling the option, they should also confirm that the existing field restrictions still meet their needs. Teams should track upstream review, the official release containing a fix, and the list of affected versions. Current evidence comes from a specific main-branch revision and a community reproduction; the public case does not cover the full service flow, and the scope of impact across all versions has not been established.</body_markdown}