Discussion: How best to catch and log 500s?

[ssoroka]

What I would like

I would like 5xx error messages go to the logs and non-descriptive errors back to the requestor. It's potentially a security issue for 5xx errors to go back to the requestor as this may leak internal system information, or even secrets

What I do now

I actually have a work-around to the question in the title. I use middleware to capture the response body (custom context) and if the status is 5xx, I spit the response body out to the logs, though this doesn't alleviate the problem of returning too much information to the requestor.

potential solution

My recommendation would be to change it so that all huma.StatusError 5xx and other unhandled errors are instead logged (or there is a handler to attach a logger), and a standard Internal Server Error type response is used (appropriate to the status code). If we are trying to give a good user experience, we could maybe give each error a unique identifier and then also pass it to the logs/error-callback-handler-thing

thoughts?

[danielgtaylor]

@ssoroka I think a middleware is the correct approach here, as you have mentioned you already do. You can capture and log the response, and replace the body as needed. You could also use a transformer to detect errors with a 5xx status and rewrite e.g. the description of error details fields.

I've mostly avoided default / built-in logging of requests/responses as this requires additional buffering in memory and should probably be optional due to the performance ramifications, but I'm open to ideas here!

[tpoterba]

Chiming in that I'm trying to create exactly the same outcome and having trouble. I think right now it's not possible to capture the error from the response in middleware without buffering, since huma takes the error (already in memory) and writes it to the connection buffer directly. I'd love a way to pull the error out more cheaply.

Thanks for your hard work on this great library, Daniel!