-
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.
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
default
special case in OpenAPI, but that isn't implemented yet (see #832)