-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: errors #1738
refactor: errors #1738
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks for cleaning this up, Pieter! I left a few minor comments and some questions to further my own understanding. I think splitting the error up by modules is a great idea, and it's something we're trying to do in the new crates as well. We should be able to use the ApiError there as well.
Co-authored-by: Oddbjørn Grødem <29732646+oddgrd@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Description of change
We used to have code that went from
ApiError
->ErrorKind
->ApiError
. During this conversion toErrorKind
we would remove friendly errors which would have been helpful to our end users. So this removes theErrorKind
enum.Instead, each module has its own
Error
know and knows has to convert it toApiError
to be as friendly as possible while not exposing sensitive information to users.With this it is also easier to isolate the proxy errors so they now return a custom
600
error code if the proxy failsHow has this been tested? (if applicable)
Starting the local stack