You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Similar to previous issues about multiple content types support like #453 or #1004
For a single endpoint, the same error code can be returned by different piece of software. For example, an application can return error details as application/json but have some infra elements in front (cloud gateway/load balancer/reverse proxy/firewall) that can block request and also return their own errors in their own format text/json/xml (usually for network errors 401,403,502,503,504).
In my use case, I realized a firewall can sometimes block requests and returns a text/plain with a string Access Forbidden. So I'm trying to represent that in my OpenAPI spec so the generated client can handle these errors properly without crashing, and this works for some of the other openapi generators. But it doesn't work well with this python client, because the content type is not validated in the generated code. It only depends on the first content declared in the schema and seems to ignore the other ones.
But in that case, I'm losing any detail about the json error.
What I expect here, is something similar to the oapi-codegen golang implementation.
If there are multiple content types defined for an error code, check that the response content type match before handling it.
So each content type can coexist and be handled separately.
casestrings.Contains(rsp.Header.Get("Content-Type"), "json") &&rsp.StatusCode==403:
// this is a json errorvardestAPIErroriferr:=json.Unmarshal(bodyBytes, &dest); err!=nil {
returnnil, err
}
response.JSON403=&destcasersp.StatusCode==403:
...// default case for text/plain error
Describe the bug
Similar to previous issues about multiple content types support like #453 or #1004
For a single endpoint, the same error code can be returned by different piece of software. For example, an application can return error details as
application/json
but have some infra elements in front (cloud gateway/load balancer/reverse proxy/firewall) that can block request and also return their own errors in their own format text/json/xml (usually for network errors 401,403,502,503,504).In my use case, I realized a firewall can sometimes block requests and returns a
text/plain
with a stringAccess Forbidden
. So I'm trying to represent that in my OpenAPI spec so the generated client can handle these errors properly without crashing, and this works for some of the other openapi generators. But it doesn't work well with this python client, because the content type is not validated in the generated code. It only depends on the firstcontent
declared in the schema and seems to ignore the other ones.So I'm getting the following implementation:
Which works for json error, but json parsing throw an exception if it's something else (like text/plain)
And if I declare
text/plain
beforeapplication/json
, I get:But in that case, I'm losing any detail about the json error.
What I expect here, is something similar to the oapi-codegen golang implementation.
If there are multiple content types defined for an error code, check that the response content type match before handling it.
So each content type can coexist and be handled separately.
OpenAPI Spec File
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: