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
Fix RetryMiddleware default exponential delay #2132
Conversation
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.
Maybe Im reading this wrong. But this does not delay anything.
Could you write a test that make sure we do actually sleep between retries?
@Nyholm the delay is not handled by the middleware but by a guzzle handler directly. The middleware sets the |
Can we get more attention from maintainers to this issue? The middleware by default does "not" back off at all since it returns 2^1/2/3/4/5 which is <100 in milliseconds now. This bombards the servers with tens of requests per second. |
I've just updated this PR's branch with latest master. I still think this should not be testing the actual delay mechanism as nothing related to that has been changed. Instead, it only changes how the delay time is calculated, @Nyholm |
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.
The issue is the units..
The option delay
expects a delay in milliseconds (ms). We are retuning 0,1,2,4,8 ms which is correct.
This PR is increasing the delay with a factor 1000,
Could you do another rebase please?
Friendly update |
RetryMiddleware::exponentialDelay was being used as-is to set the delay option in the retry middleware. However, the option requires milliseconds and this method was returning seconds.
RetryMiddleware::exponentialDelay was being used as-is to set the delay option in the retry middleware. However, the option requires milliseconds and this method was returning seconds.
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.
I rebased the PR and added a comment
Related to guzzle#2132 A fraction of use cases will expect low timeouts or no timeouts. Make it clearer that those applications should override the defaults of the middleware if upgrading to 6.5.0
Related to guzzle#2132 A fraction of use cases will expect low timeouts or no timeouts. Make it clearer that those applications should override the defaults of the middleware if upgrading to 6.5.0
Related to #2132 A fraction of use cases will expect low timeouts or no timeouts. Make it clearer that those applications should override the defaults of the middleware if upgrading to 6.5.0
RetryMiddleware::exponentialDelay
was previously returning an integer (good) representing SECONDS of delay. TheRetryMiddleware
was putting that value directly into thedelay
option for the retried request. However, the docs say that thedelay
option should be in milliseconds.If the
RetryMiddleware
was used without a custom delay function, theRetryMiddleware::exponentialDelay
is used, meaning that the delay was going to be minimal by default.