error-stack: How to give a "reason" to an error?

[kee-oth]

I'm trying to integrate error-stack into an API/web service project built with Axum. I wondering about the best way to handle differentiating "reasons" for an error.

So the specific situation I'm facing:

I'm using a 3rd party auth service to handle my authentication. This requires me sending http requests to their service. I want my route handler to know if a call received a 400 BAD_REQUEST from the auth service and pass that information along as information in the handler's response. Otherwise, I just want to say it's a 500 INTERNAL_SERVER_ERROR.

The flow looks like this:

Handler --> Internal Auth Service --> External Auth Service --> Internal Auth Service --> Handler

So there's a layer of abstraction between the Handler and the External Auth Service that blocks the handler from directly knowing if External Auth Service produces a 400 error vs any other error. What's the recommended way of passing along that information? I figure I need an "Error" and a "reason" for that Error. Then I need to access the reason and determine which reason it is.

What's the best way to handle this? I thought about attaching something and using contains but contains doesn't work with my current enum/variant setup for failure reasons. I could refactor and break out each enum variant into its own struct but that feels clunky.

Thanks!

[TimDiekmann]

Hi @kee-oth and sorry for not responding this long, I must have missed this question.

I see multiple ways to achieve this. Either way would work and it's up to your application which is the best design, use whatever works best for you.

• The most straightforward approach is an error-stack independent approach: Just put e.g. a status: i32 in your error which you pass up to your handler. This is probably the least flexible way as it's hard to put additional contextual information to the error without losing track of your error containing the status. (not really recommended unless you directly use the error)
• You could attach something like Status { code: i32 }-like object to the Report. If you see an error in your handler you could request your Status object. If it exists you can use it. If not you probably have another error.
• You could create different status objects, such as struct PermissionDenied { subject: String, permission: String, object: String } to return detailed information about your error. If you need more error codes you could add additional structs, such as NotFound { ... }. This highly depends on your use case. This is probably the most flexible way but requires you to check various different types in the Handler.
• A hybrid approach of the two above, such as enum Status { PermissionDenied {...}, NotFound {...} }.

It's correct, that you cannot search for a specific enum variant by using contains as this is completely type-based so you'd need to get the enum itself and then match it.

Hope, this helped you 🙂