You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to be sure that the right HTTP status is returned to the user if there's an error, not just a default 500 server error. If a client sees the wrong error like a 500, it will sometimes attempt a retry, which means unnecessary load and wasted retries.
If we bump uplink sometimes the errors mappings can change, e.g. when we enabled upload codepath refactor, there were cases where the wrong HTTP status was returned. There are also cases we don't catch on dev and test until someone exceeds their rate limit and we notice the wrong status is returned to them.
We need to improve the test suite so we can catch those earlier instead of when it hits production on real traffic.
Acceptance Criteria
All (or as many as possible) error mappings are tested against all the object API endpoints to make sure we're going to return the right thing.
Certain conditions like bandwidth limit exceeded are simulated to test limiting errors return 429 status on all the different endpoints.
Notes
Integration test likely makes the most sense, that's going to be closer to what the end client will see, and will test the entire API endpoint instead of just testing our object API backend.
Maybe there's a way to reduce the amount of tests we have to write by creating a Cartesian product of all the endpoints that should be mapped to the mapped errors.
The text was updated successfully, but these errors were encountered:
Goal
We want to be sure that the right HTTP status is returned to the user if there's an error, not just a default 500 server error. If a client sees the wrong error like a 500, it will sometimes attempt a retry, which means unnecessary load and wasted retries.
If we bump uplink sometimes the errors mappings can change, e.g. when we enabled upload codepath refactor, there were cases where the wrong HTTP status was returned. There are also cases we don't catch on dev and test until someone exceeds their rate limit and we notice the wrong status is returned to them.
We need to improve the test suite so we can catch those earlier instead of when it hits production on real traffic.
Acceptance Criteria
Notes
The text was updated successfully, but these errors were encountered: