-
Notifications
You must be signed in to change notification settings - Fork 31
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
feat(error): init error handling philosophy #111
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #111 +/- ##
==========================================
+ Coverage 67.16% 68.61% +1.45%
==========================================
Files 57 61 +4
Lines 5944 6163 +219
==========================================
+ Hits 3992 4229 +237
+ Misses 1667 1654 -13
+ Partials 285 280 -5 ☔ View full report in Codecov by Sentry. |
@vaibhawvipul let's talk tmrrw about this pr. this changes a bit of the expected api behavior. for example introducing 409 status code and returning error messages for unsuccessful requests instead of nil or promises. the sdk will need to adjust a bit. additionally, the client deciding which errors are retryable becomes trivial once this is merged. For grpc, we return proper grpc error codes now and status in response is only to capture dedup logic (a.k.a, did this request change something in the database or not). |
Changes
Fixes #95
Fixes #96
Fixes #98
Fixes #99
Context
Error Duality
Expected Errors
application level errors
(tolerable, expected, non-retryable) -> ResponseStatus && validation layer using json tags -- protobufplatform level errors
(tolerable, expected, retryable) -> errors.New() then convert to ResponseStatus at api layerUnexpected Errors
catastrophic
(intolerable, unexpected) -> panic()