Panic Should Generate a 500 Status Code

[mt35-rs]

When lines like this are triggered, they don't return a 500 Internal Server Error (and ideally an RFC 7807 problem report). Instead, I would expect the handler to recover and return a 500 error along with an RFC 7807 description of the problem.

I should add that it is very easy to trigger such panics as a result of various validation steps. It doesn't seem reasonable to the client to simply terminate the request without any kind of response (which is what happens now).

[mtiller]

Just to revisit this, are there really OpenAPI specs that declare 500 responses? It seems like a 500 response almost always arises as a result of a bug/flaw/unforeseen issue. My point is, it seems like a 5XX error should trigger a validation failure. I can definitely see it for 4XX because this is indicative of the client doing something wrong and, therefore, we not only need the client to know they failed but obviously enumerate (via the OpenAPI spec) all the ways the client can fail in this request. But I just don't see this with a 5XX. I think those should not trigger validation failures. My 2 cents.

[danielgtaylor]

This behavior has changed a bit in v2. There is no longer a restriction on what status codes you can set and the panic handling is now router-specific, so you can choose to use your router's panic handler, Huma v1's panic handler, or do something else.