feat: Add handling of OpenAPI endpoint default responses #1304
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
This modifies the internal Response object to use either `HTTPStatus` or a string literal "default" for status codes and modifies parsing in the `Endpoint` class to match. This additionally modifies the endpoint jinja2 template to handle this alternate response status code field by using the default response, if it exists, as the fallback case instead of the UnexpectedStatus error or returning None, and modifies the return typing to match.
This ads a function test which tests whether an endpoint with a default response option generates the expected alternate typing. This also includes a regeneration of the e2e tests after adding and endpoint utilizing default responses to the base test APIs.
|
Thanks so much! I incorporated this into #1303 since it's related |
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.
Addresses feature request for handling default responses: #832
This treats the string literal
"default"as an alternative form of status code for the internalResponseobject and handles parsing it appropriately in theEndpointclass parser. This takes the form of replacing a few instances ofHTTPStatuswith a union type alias and a conditional check on consuming that response field. Since this is now a normalResponseobject added to theEndpoint, the return type handling includes its output type appropriately.This additionally modifies the endpoint template to consume this alternative form of status code, making that default
Responsethe handler for any unspecified status codes. Since now all status codes are now handled, it removes the fallback unexpected status handler code and changes the return typing of the_parse_responsefunction to match. This breaks out the response handling into a Jinja macro so as to not duplicate that code template bit.The effect of this is that when
defaultis used as a possible response for an endpoint, it will be treated as any other response type/code would be except that it serves as the fallback for all possible HTTP responses in the runtime response parser, which is how I understand the spec to describe this feature. If a default response object is not present, there are no changes to the generated code compared to before these changes (except for the addition of a blank line, if this is a problem I still need to figure out how to make it go away, it wasn't straightforward to me).I wasn't totally sure about testing, so I added a functional test that ensures that the generated endpoint contains the changes to the return typing now that it will always return some (only if there is a default response object) and added a new endpoint to both the 3.0 and 3.1 e2e test APIs and regenerated the snapshots. I'm happy to take feedback and change how the testing works if this isn't appropriate.