Object-valued query parameters do not use OpenAPI’s exploded form
A request such as ?page=0&size=100 did not populate $.query.pageable and, once request validation existed, was rejected as missing the required pageable parameter.
- Report
- Issue #1933
- Reporter
- dissemond-bitside
- Reported
- April 21, 2026
- Reported version
- 2.9.0
- Primary matched window
- Included
- First affected release entered primary window
- No
- Origin classification
- Pre-existing before 2026
- Classification confidence
- High
- Chronology confidence
- Medium
- Accepted correction
- PR #1935
- First fixed release
- 2.10.0
- Report to release
- 4 days
Finding
Request validation made the mismatch more visible in 2026, but it did not create the underlying deserialization omission. The same exploded input could not have produced the declared object in 2025.
This is the clearest latent-defect case. A new validator changed the symptom from incorrectly shaped handler data to a visible 400 response, but the supported OpenAPI serialization could not be consumed correctly before the validator existed either. Under the audit rules, increased visibility is not a new regression.
Evidence trail
Origin
Confirmed affected by: 02378893, committed November 12, 2022; confirmed affected release 0.13.1. The earliest confirmed OpenAPI-aware query conversion still exposed the web framework’s flat query object and did not assemble form-exploded object parameters under their declared name.
Source history and behavioral evidence
The flat query assignment is already present when OpenAPI-aware parameter conversion shipped in 0.13.1 and persists through the 2025 boundary. The later TypeScript conversion preserved rather than introduced it. The fix adds OpenAPI style/explode-aware assembly to both validation and handler input.
Release chronology
The omission is confirmed in 0.13.1; the audit does not claim that commit is the exact first possible origin. Correct exploded-object support shipped in 2.10.0 four days after the report.