Error types no longer strongly typed
bruceharrison1984 opened this issue · comments
Bruce Harrison commented
Description
After upgrading to the newer @hey-api/client-fetch
, the data
object is correctly typed, but the error
type is now untyped (previously it was correctly typed)
Spec
...
"schema":{
"ErrorPayload": {
"type": "object",
"properties": {
"message": { "type": "string" },
"detail": { "type": "string" },
"status": { "type": "number" },
"stack": { "type": "string" }
},
"required": ["message", "status"]
},
...
"paths": {
"/resources/users": {
"get": {
"tags": ["Users"],
"security": [{ "Bearer": [] }],
"parameters": [
{
"schema": { "type": "number" },
"required": true,
"name": "limit",
"in": "query"
},
{
"schema": { "type": "number" },
"required": true,
"name": "offset",
"in": "query"
}
],
"responses": {
"200": {
"description": "array of Users",
"content": {
"application/json": {
"schema": {
"type": "array",
"items": { "$ref": "#/components/schemas/UsersResult" }
}
}
}
},
"4XX": {
"description": "common error response",
"content": {
"application/json": {
"schema": { "$ref": "#/components/schemas/ErrorPayload" }
}
}
}
}
},
...
This is easy enough to work-around by forcibly casting the objects, but I presume this is an oversight.
Lubos commented
I am actually surprised this worked before the standalone client. Either way, I think it's because of the 4XX status code. I am adding support for such codes in the next release, please let me know if that fixes it for you!
Kostiantyn Ko commented
Lubos commented
@kostia1st that sounds like a separate issue no?
Kostiantyn Ko commented
@mrlubos yep, just created one