-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[HttpClient] provide response body to the RetryDecider #38289
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
1c29567
to
cde9938
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.
content-type: application/x-amz-json-1.1
for my understanding, this means you're going to add a decider in async-aws that will chck both the status code and this specific content-type to decide to wait for the body, isn't it?
src/Symfony/Component/HttpClient/Retry/RetryDeciderInterface.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpClient/Retry/RetryDeciderInterface.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpClient/Retry/RetryDeciderInterface.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpClient/Retry/RetryBackOffInterface.php
Outdated
Show resolved
Hide resolved
yes. The decider should avoid as possible downloading the body. It can take a quick decision when statusCode is 2xx, 429, 5xx... Or content-type is unknow or content-length is too big. but in some case (status = 400 + contentType = json + content-length < XXX) then it'll ask to the client to provide the body to take the decision. |
d4da9b2
to
d0844c2
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.
(I force-pushed a patch on AsyncResponse
and confirmed it works)
Confirmed, it works. I pushed a commit about fixing wrong exception namespace |
Thank you @jderusse. |
The body is read once so getContent don't work after that:
Sorry if my usage is wrong... <?php
declare(strict_types=1);
use Symfony\Component\HttpClient\CurlHttpClient;
use Symfony\Component\HttpClient\Retry\ExponentialBackOff;
use Symfony\Component\HttpClient\Retry\HttpStatusCodeDecider;
use Symfony\Component\HttpClient\RetryableHttpClient;
require __DIR__ . '/vendor/autoload.php';
$client = new RetryableHttpClient(new CurlHttpClient(), new HttpStatusCodeDecider(), new ExponentialBackOff(), 1);
$resp = $client->request('GET', 'https://httpbin.org/status/429');
var_dump($resp->getContent(false)); |
…derusse) This PR was merged into the 5.2-dev branch. Discussion ---------- [HttpClient] Fix exception triggered with AsyncResponse | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | #38289 (comment) | License | MIT | Doc PR | / When a request is replayed with the AsyncResponse and the 2nd request failed, users get an exception even when they pass `$throw=false`. In fact, there are 2 exceptions: 1. Cannot get the content of the response twice: buffering is disabled. https://github.com/symfony/symfony/blob/73ca97c97ab4c4fc9a7bca5fb4339fca22e0cfa1/src/Symfony/Component/HttpClient/Response/CommonResponseTrait.php#L51-L68 Because CommonResponseTrait::$content is null and `self::stream` yield only the LastChunk. The content is stays null 2. HTTP/2 429 returned for "https://httpbin.org/status/429" https://github.com/symfony/symfony/blob/73ca97c97ab4c4fc9a7bca5fb4339fca22e0cfa1/src/Symfony/Component/HttpClient/Response/AsyncResponse.php#L209-L225 Because on the second request passthru is null, it didn't disable the the exception thrown on destruct for the wrapped response. This Commits ------- 3aedb51 [HttpClient] Fix exception triggered with AsyncResponse
…derusse) This PR was merged into the 5.2-dev branch. Discussion ---------- [HttpClient] Fix exception triggered with AsyncResponse | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | symfony/symfony#38289 (comment) | License | MIT | Doc PR | / When a request is replayed with the AsyncResponse and the 2nd request failed, users get an exception even when they pass `$throw=false`. In fact, there are 2 exceptions: 1. Cannot get the content of the response twice: buffering is disabled. https://github.com/symfony/symfony/blob/73ca97c97ab4c4fc9a7bca5fb4339fca22e0cfa1/src/Symfony/Component/HttpClient/Response/CommonResponseTrait.php#L51-L68 Because CommonResponseTrait::$content is null and `self::stream` yield only the LastChunk. The content is stays null 2. HTTP/2 429 returned for "https://httpbin.org/status/429" https://github.com/symfony/symfony/blob/73ca97c97ab4c4fc9a7bca5fb4339fca22e0cfa1/src/Symfony/Component/HttpClient/Response/AsyncResponse.php#L209-L225 Because on the second request passthru is null, it didn't disable the the exception thrown on destruct for the wrapped response. This Commits ------- 3aedb51dd8 [HttpClient] Fix exception triggered with AsyncResponse
…derusse) This PR was merged into the 5.2-dev branch. Discussion ---------- [HttpClient] Fix exception triggered with AsyncResponse | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | symfony/symfony#38289 (comment) | License | MIT | Doc PR | / When a request is replayed with the AsyncResponse and the 2nd request failed, users get an exception even when they pass `$throw=false`. In fact, there are 2 exceptions: 1. Cannot get the content of the response twice: buffering is disabled. https://github.com/symfony/symfony/blob/73ca97c97ab4c4fc9a7bca5fb4339fca22e0cfa1/src/Symfony/Component/HttpClient/Response/CommonResponseTrait.php#L51-L68 Because CommonResponseTrait::$content is null and `self::stream` yield only the LastChunk. The content is stays null 2. HTTP/2 429 returned for "https://httpbin.org/status/429" https://github.com/symfony/symfony/blob/73ca97c97ab4c4fc9a7bca5fb4339fca22e0cfa1/src/Symfony/Component/HttpClient/Response/AsyncResponse.php#L209-L225 Because on the second request passthru is null, it didn't disable the the exception thrown on destruct for the wrapped response. This Commits ------- 3aedb51dd8 [HttpClient] Fix exception triggered with AsyncResponse
Some servers, like AWS, does not always return standard HTTP code. The strategy needs to parse the body to take a decision.
example:
This PR update the
RetryDeciderInterface
interface to let the decider notifying the Client when it need the body to take a decision. in that case, the Client, fetch te client, and call again the decider with the full body.usage