Skip to content

Conversation

teandr
Copy link

@teandr teandr commented Aug 17, 2025

No description provided.

@teandr teandr requested a review from ksassnowski as a code owner August 17, 2025 10:03
'retryOnStatus' => [500, 502, 503, 504],
'maxRetries' => 3,
'initialDelay' => 1000,
'delayMultiplier' => 2.0,
Copy link
Contributor

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, good idea. Implemented.

@ksassnowski
Copy link
Contributor

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.

@teandr
Copy link
Author

teandr commented Aug 27, 2025

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 !

teandr added 5 commits August 31, 2025 12:01
RequestSchedulerInterface was not registered as singleton.
Engine and RetryMiddleware received different scheduler instances.
This resulted in separate queues instead of a shared one.
@teandr teandr requested a review from ksassnowski August 31, 2025 05:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants