Extend HttpClient retry logic to retry on 502/503/504#1446
Open
nevinera wants to merge 1 commit intoShopify:mainfrom
Open
Extend HttpClient retry logic to retry on 502/503/504#1446nevinera wants to merge 1 commit intoShopify:mainfrom
nevinera wants to merge 1 commit intoShopify:mainfrom
Conversation
Previously, HttpClient retries requests (when 'tries' was large enough) in two conditions: on 429 (obeying the retry-after header) and on 500 (retrying after 1 second). The 502 (Bad Gateway), 503 (Service Unavailable), and 504 (Gateway Timeout) statuses are all _infrastructure_ prompted conditions, but from the caller's perspective they are all equivalent to a 500: "the service failed to handle my request". Allowing retries to apply to these statuses is natural and appropriate. Add a small section to the docs describing the behavior of the 'tries' parameter in more detail, including the updated behavior.
e42110a to
cbdc083
Compare
This file contains hidden or 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
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.
Description
We've been encountering sporadic 502s from the storefront API fairly constantly (for months at minimum) - I've wrapped a retry layer around it on our end, but it seemed like it would fit better inside the gem itself. I haven't hit 503s/504s from this service so far, but those are also typical indications of an overloaded node or transient infrastructure issue, so I included them as well.
The impact of the change should be that, for requests with retries specified, 502/503/504 response codes are treated just like 500 errors - they wait one second and then retry, up to a total
triesrequests.There was no documentation of the behavior of the
triesparameter; I added a section todocs/usage/rest.mdexplaining it, but I'm happy to remove that change if it's too much detail for the doc.How has this been tested?
I've added HttpClient tests ensuring the new codes get retried like 500s do. I can't produce the 502s on the real gem without significant api request-load (it's occurring for less than 0.05% of requests), but if that's expected I can install the forked gem in production for a few days as well?
Checklist: