Add support for "XX" status code specifications #973
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks! We'll probably want to add a new type with some template logic that can check ranges of status codes. I think as-is this will generate a ton of |
|
Superseded by #1303 |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Aug 26, 2025
> [!IMPORTANT]
> Merging this pull request will create this release
## Breaking Changes
### Change some union variant names
When creating a union with `oneOf`, `anyOf`, or a list of `type`, the
name of each variant used to be `type_{index}`
where the index is based on the order of the types in the union.
This made some modules difficult to understand, what is a
`my_type_type_0` after all?
It also meant that reordering union members, while not a breaking change
to the API, _would_ be a breaking change
for generated clients.
Now, if an individual variant has a `title` attribute, that `title` will
be used in the name instead.
This is only an enhancement for documents which use `title` in union
variants, and only a breaking change for
_inline models_ (not `#/components/schemas` which should already have
used more descriptive names).
Thanks @wallagib for PR #962!
## Features
### Support patterned and default HTTP statuses
HTTP statuses like `2XX` and `default` are now supported!
A big thank you to:
- @PSU3D0 for PR #973 (eons ago 😅)
- @obs-gh-peterkolloch for PR #1300
- @goodsonjr for PR #1304
Closes #1271 and #832
> [!NOTE]
> Custom template users: the `endpoint.responses` type has changed quite
a bit. Check out #1303 for the changes.
Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As indicated in the OpenAPI specification, specifications may specify a range of response codes. See the following excerpt:
Any HTTP status code can be used as the property name, but only one property per code, to describe the expected response for that HTTP status code. This field MUST be enclosed in quotation marks (for example, "200") for compatibility between JSON and YAML. To define a range of response codes, this field MAY contain the uppercase wildcard character X. For example, 2XX represents all response codes between [200-299]. Only the following range definitions are allowed: 1XX, 2XX, 3XX, 4XX, and 5XX. If a response is defined using an explicit code, the explicit code definition takes precedence over the range definition for that code.
This was missing from the library. This PR fixes that. Cheers!