-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[HttpClient] simplify retry mechanism around RetryStrategyInterface #38532
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
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.
I like the new methods signatures.
Don't forget to update the FrameworkExtension
src/Symfony/Component/HttpClient/Retry/GenericRetryStrategy.php
Outdated
Show resolved
Hide resolved
5c31b3e
to
4148f78
Compare
4148f78
to
544c3e8
Compare
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.
Thank you @nicolas-grekas. It's simpler like this.
use Symfony\Contracts\HttpClient\Exception\TransportExceptionInterface; | ||
|
||
/** | ||
* Decides to retry the request when HTTP status codes belong to the given list of codes. |
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.
This should document that its delay implementation is an exponential backoff. That got lost when naming it generic
.
This PR was merged into the 5.x branch. Discussion ---------- Fix documentation about RetryStrategy Change introduced in symfony/symfony#38532 Commits ------- 19521c3 Fix documentation about RetryStrategy
Replaces #38466
I feel like the mechanism behind RetryableHttpClient is too bloated for no pragmatic reasons.
I propose to merge RetryDeciderInterface and RetryBackoffInterface into one single RetryStrategyInterface.
Having two separate interfaces supports no real-world use case. The only implementations we provide are trivial, and they can be reused by extending the provided GenericRetryStrategy implementation if one really doesn't want to duplicate that.
The methods are also simplified by accepting an AsyncContext as argument. This makes the signatures shorter and allows accessing the "info" of the request (allowing to decide based on the IP of the host, etc).
/cc @jderusse