fix(api domain)!: improve status handling in API Domain; do not return an error on 404 #870
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Properly handle cases where a non-200 status code is returned and the status text is in the response body - otherwise basically any error would end up in the body as a string (thanks, http/2) and result in an unmarshalling error. Changes: - added a "status" field, which is populated with the http.Status if included in the response, or the text from the http.StatusCode if not. - don't error on a 404 (I swear I did that already, so I guess I did it for reals this time) - don't try to unmarshal the body into a json object if the return isn't a 2XX I'm sure I'm missing more edge cases, and welcome any suggestions, but hopefully this is better!
mildwonkey
force-pushed
the
mildwonkey/api-status-handling
branch
from
250bf50 to
06b2a56
Compare
brandtkeller
approved these changes
Jan 8, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Properly handle cases where a non-200 status code is returned and the status text is in the response body - otherwise basically any error would end up in the body as a string (thanks, http/2) and result in an unmarshalling error.
Changes:
I'm sure I'm missing more edge cases, and welcome any suggestions, but hopefully this is better!
There is a bit of a breaking change, excep;t it's the one I thought I'd already tackled (missed a big one, I guess): we don't return an error on a 404 response (or, theoretically, any other response that isn't very genuinely invalid - the bits I already took care of?); instead we return a DR with the status code and message.
Type of change
Checklist before merging