This release teaches the parameter binders about OpenAPI 3.1 multi-type unions, and fixes a long-standing panic on the request binding path. As with v1.6.0, new behavior is controlled by explicit settings rather than assumptions: binding stays exactly as it was unless the new options are used.
Notable Changes
Binding OpenAPI 3.1 multi-type union parameters
OpenAPI 3.1 allows a parameter's type to be a list, such as type: [string, integer]. Go has no type meaning "one of these", so generated code maps such parameters to any — which the binders previously rejected outright with can not bind to destination of type: interface, making these parameters unusable.
The binder options structs (BindStyledParameterOptions, BindQueryParameterOptions, BindStringToObjectOptions) gain a Types []string field carrying the union's member list. It is only consulted when the destination is an any; binding into every concrete Go type is completely unchanged. The value binds to the first member that parses, trying boolean, integer, number, then string — most restrictive first, since a string always parses. Member detection follows the JSON number grammar (RFC 8259), so values like 007 or +1 bind as strings rather than being silently reinterpreted as numbers.
The bound value's dynamic type is always one of bool, int64, float64, string, or (with format: byte) []byte, so a handler's type switch is stable regardless of what the spec's format says. Applications that want format: int32 / format: float to narrow the produced types to int32 / float32 can opt in via a new package-level setting, following the same pattern as DefaultQueryEncoder from v1.6.0:
func init() {
runtime.NarrowUnionNumericFormats = true
}Generator support for emitting Types is landing in oapi-codegen separately; the runtime side ships first so generated code can rely on it. Arrays of unions and deepObject-style parameters are not covered yet — see the Types field documentation for the exact scope.
Fix for a panic when binding numeric values into slice destinations
Since v1.2.0, binding a string that happens to parse as an integer into a non-[]byte slice destination panicked with reflect: call of reflect.Value.OverflowInt on slice Value, instead of returning an error. This was reachable from generated code on the request path: a nullable.Nullable[[]string] query parameter using the default form/explode serialization would panic on ?p=123 while returning a normal binding error on ?p=abc. These cases now return a clean can not bind to destination of type: slice error.
🚀 New features and improvements
- Bind OpenAPI 3.1 multi-type union parameters into any destinations (#154) @mromaszewicz, @claude
🐛 Bug fixes
- Fix panic binding numeric values into non-byte slice destinations (#156) @mromaszewicz, @claude
✍ Other changes
- chore: use go mod tidy instead of tidied (#148) @alexandear
📦 Dependency updates
6 changes
- chore(deps): update github/codeql-action action to v4.37.7 (#152) @renovate[bot]
- chore(deps): update release-drafter/release-drafter action to v7.7.0 - autoclosed (#151) @renovate[bot]
- chore(deps): update github/codeql-action action to v4.37.5 (#150) @renovate[bot]
- fix(deps): update module github.com/labstack/echo/v5 to v5.3.1 - autoclosed (#149) @renovate[bot]
- chore(deps): update release-drafter/release-drafter action to v7.6.0 (#147) @renovate[bot]
- chore(deps): update github/codeql-action action to v4.37.2 (#146) @renovate[bot]
Sponsors
We would like to thank our sponsors for their support during this release.
- No new contributors
