-
-
Notifications
You must be signed in to change notification settings - Fork 77
Retry middleware #281
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
base: main
Are you sure you want to change the base?
Retry middleware #281
Conversation
'retryOnStatus' => [500, 502, 503, 504], | ||
'maxRetries' => 3, | ||
'initialDelay' => 1000, | ||
'delayMultiplier' => 2.0, |
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 would prefer if we combined initialDelay
and delayMultiplier
into a single backoff
option that takes an array of integers.
So a backoff of [1, 5, 10]
would mean the first retry happens after one second, the second after 5, the third after 10 seconds and 10 seconds for every subsequent request if maxRetries
is greater than 3.
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.
Yes, good idea. Implemented.
Thanks for the PR! Looks good overall but I have a few comments that need to be addressed first. Please check them out when you find the time. |
Hi, Kai. Hope you're having a good week. I'm writing to follow up on the pull request. I've addressed your previous comments and implemented the array-based backoff strategy, which is a much cleaner approach – thank you for the suggestion. The implementation now allows a backoff option (e.g., [1, 5, 10]) to define the retry delays in seconds. It then pushes this value into the request's options under the delay key. Guzzle itself, as per its documentation, is responsible for honoring this option and pausing before sending the next request. This approach delegates the actual waiting to the HTTP client, which is a best practice. Would you mind reviewing the updated implementation when you get a chance? I believe it now cleanly combines the flexible configuration you suggested with the robust execution provided by Guzzle. Please let me know if you have any further questions or if there's anything else you'd like to see adjusted. Thank you for your time ! |
RequestSchedulerInterface was not registered as singleton. Engine and RetryMiddleware received different scheduler instances. This resulted in separate queues instead of a shared one.
2771808
to
5f19f52
Compare
No description provided.