Fixed a bug when Retry-After is 0, it should use min wait time.#170
Open
evanchaoli wants to merge 1 commit intohashicorp:mainfrom
Open
Fixed a bug when Retry-After is 0, it should use min wait time.#170evanchaoli wants to merge 1 commit intohashicorp:mainfrom
evanchaoli wants to merge 1 commit intohashicorp:mainfrom
Conversation
Signed-off-by: Evan <chaol@vmware.com>
|
|
1 task
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
3 participants
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.
In my test, I set rate limit
block_interval=5 rate=1, then the first response hadRetry-After: 4and the second response hadRetry-After: 0, so that the second retry still failed.When server responds
Retry-After: 0, tests prove that immediate retry will fail also. Thus I think in that case MinWaitTime should be used.The other approach I was thinking is to always return
Retry-After + 1. When rate is 1, that should work better. As I my test case rate limit set toblock_interval=5 rate=1, when hit rate limit, first 429 response will haveRetry-After: 4, after 4 seconds, retry will hit 429 again withRetry-After: 0, then if retry immediately, if will hit 429 again. Thus if backoff isRetry-After + 1, that should work better.But if
block_interval=1, if we doRetry-After + 1, then retry interval will always be 1 second, which sounds not good, thus I chose the current approach I implemented in this PR.