Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

openapi: deal with error return types #7

Closed
ahl opened this issue Jun 26, 2020 · 2 comments
Closed

openapi: deal with error return types #7

ahl opened this issue Jun 26, 2020 · 2 comments

Comments

@ahl
Copy link
Collaborator

ahl commented Jun 26, 2020

We may do this in several PRs, but the end state should be that the various error types are well-captured for each endpoint. This will likely require us to think more carefully about the specific return types we want to expose to developers, the appropriate granularity, and the types of remediation we expect developers to take in the case of failures.

There are types of failures where we have more information:

  • we could provide detailed information about input validation failures
  • we could provide specific guidance about retries in the case of 503 (service unavailable)
  • etc.

Ideally we should make use of the components/responses field of OpenAPI to minimize the number of times these shared error structures are represented in the OpenAPI document.

@WasabiFan
Copy link

Would it be correct to say that currently there is no way to output errors in the responses section of an endpoint's OpenAPI doc? (Even manually, barring postprocessing of the JSON structure.) Currently, it looks like only one possible response can be modeled in the registered routes.

@hawkw
Copy link
Member

hawkw commented Dec 4, 2024

I think #1180 fixed this! Endpoint handler functions can now return user-defined error types and they have response schemas generated in OpenAPI.

@hawkw hawkw closed this as completed Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants