-
Notifications
You must be signed in to change notification settings - Fork 9
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
chore: distinguish bad device token errors #257
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.
Why are we returning a 400 when a dependency fails? The client has nothing to do with it, wouldn't it be better with a 503 instead?
That would also mean we should stop monitoring 5xx and only monitor 500 to see actual server errors. |
As a possible solution, we can check if the error is |
That would be nice since it would let us still see the actual errors instead of hiding everything under 400s |
We have a specific error for the |
b83dce1
to
a918363
Compare
a918363
to
adf0860
Compare
Description
We have a lot of
apns(unregistered)
HTTP 500 errors. Anunregistered device token
is not an internal server error and should be distinguished from it.BadDeviceToken
error should be used for such cases.BadDeviceToken
error type to have a string argument that reflects a certain device token error.Resolves #256
How Has This Been Tested?
Not tested.
Due Diligence