v2.8.0: OpenAPI 3.1, fewer assumptions, and a giant bug hunt #2478
mromaszewicz
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
OpenAPI 3.1, webhooks, callbacks, and a lot of polish
This is a big one. After a long stretch of internal refactoring across the last couple of releases, we've been able to land some features that have been on the wishlist for years, most notably initial OpenAPI 3.1 support. As always, the full, automatically-generated changelog is at the bottom, and the sections below call out the things you'll actually want to read before upgrading.
When this project was originally released, it supported a narrow set of OpenAPI features, and over time, it has grown from generating code for hand crafted, structurally tight specifications, to very complex, and often messy specifications. I don't think we can ever handle every specification, however, over time, we're going to give users control over as many behaviors as possible, so that our assumptions, which can't be right for everyone, are configurable. More changes of this form will continue to come in the upcoming releases.
Before you upgrade
A couple of housekeeping notes up front:
runtimev1.6.0 or newer. Several features in this release (the newDurationtype, escaped-path-parameter handling, typed response headers) rely on functionality that landed in the runtime, so make sure you're ongithub.com/oapi-codegen/runtimev1.6.0+ when you regenerate.☢️ Breaking changes
We try hard to avoid breaking changes, and when we can't, to make them narrow or configurable.
Trailing-slash routes on the
net/httpserver no longer act as catch-alls (#2460)This one only affects the standard-library
net/httpserver (the one built onServeMux). It's a correctness fix, which is why we decided to just do it rather than hide it behind a flag.Here's the problem: a
ServeMuxpattern ending in/matches the entire subtree beneath it, but an OpenAPI path ending in/means exactly that path and nothing deeper. So we were both mismatching the spec's semantics and, worse, panicking at registration time when two such patterns overlapped ambiguously. We now anchor any trailing-slash path with{$}so it matches only what the spec says it should.The result: if your spec has trailing-slash paths, requests to deeper URLs that used to get swallowed by the catch-all will now correctly return
404. (ServeMuxstill issues its usual307redirect from the un-slashed path to the canonical one.) If you were relying on the old subtree behavior, that was never what your spec actually declared.Security scopes are no longer emitted by default (#2440)
Generated servers used to emit per-scheme context key types (
bearerAuthContextKeyand friends), scope constants (BearerAuthScopes), and per-operation context stores that flattened your spec'ssecurityrequirements into the request context. We've stopped emitting these by default.The reason is that this machinery is fundamentally broken: it can't represent alternative (OR), combined (AND), or anonymous (
{}) security requirements, so it quietly encourages people to build authorization logic on top of a representation that doesn't actually capture what the spec says. Authentication and authorization belong in the request validation middleware, which evaluates the real security requirements directly.If you genuinely need the old emission back, there's an opt-in flag:
We'd encourage you to migrate to the validation middleware instead, but the flag is there if you need a bridge.
🎉 Notable changes
OpenAPI 3.1 support (#2336)
Finally, after several years of requests, we've been able to close #373, adding OpenAPI 3.1 support. We've added support for callbacks and webhooks, and we support several OpenAPI 3.1 idioms, such as flexible enums via oneOf, as well as
type: [T, "null"]-style nullability. This is initial support, so we'd love to hear about the specs it doesn't yet handle well.While
oapi-codegenwould love to see an increase in sponsorship to make the project more sustainable, if we had to choose, we'd prefer to see that money go upstream to kin-openapi, which is the OpenAPI library that powers us and a large part of the Go ecosystem.We're working to sponsor Pierre, the solo kin-openapi maintainer, with a significant portion of our own funds, and really hope that y'all consider sponsorship to support the important work that he does.
The OpenAPI 3.1 support in kin-openapi wouldn't have been possible without Pierre's maintainership, and a number of external contributors.
Optionally hoist anonymous schemas into named types (#2366)
You can now opt in to having every anonymous, inline schema hoisted into a top-level named type, with a name derived from its location (path) in the spec. If you've ever wanted a real, referenceable Go type for some deeply-nested inline object instead of an anonymous struct, this is for you.
We now validate the spec before generating (#2435)
oapi-codegenhas always been extremely permissive about the specs it accepts, which is great until a malformed spec leads to non-compiling generated code and a confusing debugging session. We now run a validation pass over the spec before code generation, which lets us catch a class of errors that are hard to detect during codegen and abort early with a meaningful error message instead of emitting broken Go. As a bonus, this makes us considerably more resilient to malicious or garbage input.Handlers are now registered in spec order (#2465, #2477)
Some routers make matching decisions based on the order in which handlers are registered. To make behavior predictable and match your intent, we now emit route registrations in the same order the paths appear in your spec, so you have control of the order by controlling the order in which you declare them. To go back to the previous behavior, add this to your configuration:
format: durationnow maps to a realDurationtype (#2458)A
type: string, format: durationschema used to fall through to a plain Gostring, leaving all the parsing and validation up to you. The runtime now ships an RFC 3339Durationtype (added in runtime v1.5.0), and the default type mapping resolvesformat: durationto it, right alongside the other formats likedate,uuid,email, andbinary.This does change the generated type for specs already using
format: duration. If you'd rather keep the old plain-stringbehavior, map the format back explicitly in your config:The rest of the notables and new features
A quick rundown of the other behavior-affecting changes worth knowing about:
{}entry in asecuritylist (i.e. "auth optional here") is now handled correctly.deprecatedGodoc is emitted correctly (#2405, thanks @jamietanna) — deprecation markers now land on the right declarations so your tooling actually flags them.There's a great deal more in the way of bug fixes below — this release fixes a large batch of long-standing issues in the aggregate-type (
allOf/anyOf/oneOf), discriminator, and external-$refcode paths. Thank you to everyone who reported issues and sent PRs.☢️ Breaking changes
🎉 Notable changes
🚀 New features and improvements
🐛 Bug fixes
📝 Documentation updates
👻 Maintenance
golangci-lint's install script onmain(lint: migrate togolangci-lint's install script onmain#2376) @jamietannamake tidy(chore(renovate): correctly runmake tidy#2374) @jamietanna📦 Dependency updates
33 changes
Sponsors
We would like to thank our sponsors for their support during this release.
We'd also like to thank Greptile for allowing our project to use their code review system.
This discussion was created from the release v2.8.0: OpenAPI 3.1, fewer assumptions, and a giant bug hunt.
Beta Was this translation helpful? Give feedback.
All reactions