openapi codegen: Only status 200 API response data is typed?

[dungkhuc]

It seems that codegen ignores all other status codes in my openapi doc. Is this intended?

[phryneas]

RTK Query knows only "success" and "failure" - and since an error can be pretty much everything, including "connection lost", "parsing of answer failed", "error in user code" or "timed out", the failure is pretty generic. So the codegen only extracts the success type because there is no explicit way of handling endpoint-specific error types.

[sashless]

While i aggree with you that error handling might differ for everyone, i think that the error response types would still be useful regardless of the actual error handling.

Could we implement that error response types are at least generated like successful response types ?

[mankittens]

Throwing my 2 cents in the ring: I think this is an important feature. I'm currently evaluating RTK Query for use at my company, and it would be very useful for us to have generated types that reflect what unsuccessful status codes are defined in the OpenAPI schema

Forgive my lack of detailed knowledge around how RTK Query is implemented, but I would guess that the feature requested could be a relatively minor change to the package typing and code generation module, with no changes to the core functionality. Am I off base?

[markerikson]

@mankittens : so with the caveats that Lenz has done all the codegen work so far and I haven't actually looked at any of that myself, I'd guess there's two different aspects to the question:

• Modifying how the codegen packages interact with the schemas and what they output would be completely independent of RTKQ's own functionality, yes
• But on the other hand, RTKQ itself does have some specific behaviors and API design constraints, like what Lenz pointed out with requests either being "succeeded" or "failed".

I haven't tried to use the codegen yet, so I'm not sure what "successful response types" are being generated or how those end up getting used. But in general, yeah, codegen changes are separate from RTKQ logic.

Lenz has been extremely busy with things lately and hasn't had time to work on any codegen fixes or features for a while, but I think he said in another issue he's hoping to find time to do so in "a few weeks". If you or anyone else is interested in helping improve the codegen tools, we'd definitely appreciate contributions!

[phryneas]

RTK Query generally knows a "known success state" and an "unknown error state". The error state could be changed, but errors are still handled globally, and there are no different error types per-endpoint.

So to handle this, all known states would have to be handled as "success", which would mean that even for a 403, in your hook you would have isSuccess: true, and isError: false. Then you could have { data: { status: 403, value: ... } } - I'm at this point not sure if that is desirable.

Allowing per-endpoint known errors would definitely need changes with the core.