-
|
From manual testing, it looks like the generated clients only attempt to parse the response body if the return code is 200. I have an endpoint that can return a 400 status code, in which case the body will be the same type as if it were a 200 response code, but it will contain extra information about what went wrong. The point of this endpoint is to run a validation, returning 200 if the validation passes and 400 if it doesn't. Right now, consumers would have to avoid the What's the recommendation here? Should I use templates/manually update the generated parse code to include 400 error codes? Did I do something in my openapi schema that resulted in this behavior by mistake? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment · 3 replies
-
|
The "/responses/multiple-statuses": {
"get": {
"responses": {
"200": {
"description": "Success",
"content": {
"application/json": {
"schema": {
"type": "object",
"title": "Success",
"properties": {
"success": {
"type": "boolean"
}
}
}
}
}
},
"201": {
"description": "Created",
"content": {
"application/json": {
"schema": {
"type": "object",
"title": "Created",
"properties": {
"created": {
"type": "boolean"
}
}
}
}
}
}
}
}
}Generates two classes: So if there are cases where those are not generated, I think that's a bug. |
Beta Was this translation helpful? Give feedback.
-
|
In my case, my parsed field is of type def _parse_response(
*, client: Union[AuthenticatedClient, Client], response: httpx.Response
) -> Optional[Union[HTTPValidationError, ValidationReport]]:
if response.status_code == HTTPStatus.OK:
response_200 = ValidationReport.from_dict(response.json())
return response_200
if response.status_code == HTTPStatus.UNPROCESSABLE_ENTITY:
response_422 = HTTPValidationError.from_dict(response.json())
return response_422
if client.raise_on_unexpected_status:
raise errors.UnexpectedStatus(response.status_code, response.content)
else:
return NoneThe actual parsing only happens when the status code is either 200 or 422, otherwise |
Beta Was this translation helpful? Give feedback.
-
|
or are you saying that I need to explicitly document the return code in the schema (I'll try that now) |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, it will only attempt to parse a model from a known status code. If the status code's schema isn't documented, it won't know what to parse. There is the |
Beta Was this translation helpful? Give feedback.
Yeah, it will only attempt to parse a model from a known status code. If the status code's schema isn't documented, it won't know what to parse. There is the
defaultspecial case in OpenAPI, but that isn't implemented yet (see #832)