Fixed a bug when Retry-After is 0, it should use min wait time. #170
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: 4
and 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.