-
Notifications
You must be signed in to change notification settings - Fork 282
Add a new RateLimitLinearJitterBackoff policy #260
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -638,6 +638,23 @@ func LinearJitterBackoff(min, max time.Duration, attemptNum int, resp *http.Resp | |
| return time.Duration(jitterMin * int64(attemptNum)) | ||
| } | ||
|
|
||
| // RateLimitLinearJitterBackoff wraps the retryablehttp.LinearJitterBackoff. | ||
| // It first checks if the response status code is http.StatusTooManyRequests | ||
| // (HTTP Code 429) or http.StatusServiceUnavailable (HTTP Code 503). If it is | ||
| // and the response contains a Retry-After response header, it will wait the | ||
| // amount of time specified by the header. Otherwise, this calls | ||
| // LinearJitterBackoff. | ||
| func RateLimitLinearJitterBackoff(min, max time.Duration, attemptNum int, resp *http.Response) time.Duration { | ||
| if resp != nil { | ||
| if resp.StatusCode == http.StatusTooManyRequests || resp.StatusCode == http.StatusServiceUnavailable { | ||
| if sleep, ok := parseRetryAfterHeader(resp.Header["Retry-After"]); ok { | ||
| return sleep | ||
| } | ||
| } | ||
| } | ||
|
Comment on lines
+648
to
+654
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does it makes sene to ignore
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe the only other case where a Retry-After header should be sent is with a redirect status. The HTTP client will do redirecting as part of I can update this to parse the header regardless of status code There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Tbh, I'm not really sure what is the correct way to handle the header. If there is a req to handle other status codes, we'll deal with it then. I'll approve the PR for now. Thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see you've already push a commit to ignore the status code. I'm okay with either way of handling the header. |
||
| return LinearJitterBackoff(min, max, attemptNum, resp) | ||
| } | ||
|
|
||
| // PassthroughErrorHandler is an ErrorHandler that directly passes through the | ||
| // values from the net/http library for the final request. The body is not | ||
| // closed. | ||
|
|
||
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.
After removing the status codes checks, the documentation is no longer correct. Let's either fix this or undo the commit.
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.
Reverted the commit