Instance of "Symfony\Component\HttpClient\Response\CurlResponse" is already consumed and cannot be managed by "Symfony\Component\HttpClient\RetryableHttpClient". A decorated client should not call any of the response's methods in its "request()" method.

[victor-upmeet]

Hi,

When using symfony/messenger with symfony/amazon-sqs-messenger, every once in a while we get the following error:

Instance of "Symfony\Component\HttpClient\Response\CurlResponse" is already consumed and cannot be managed by "Symfony\Component\HttpClient\RetryableHttpClient". A decorated client should not call any of the response's methods in its "request()" method.
Stack Trace:
#0 /var/www/vendor/symfony/http-client/Response/AsyncResponse.php:286
#1 /var/www/vendor/symfony/http-client/Response/ResponseStream.php:47
#2 /var/www/vendor/async-aws/core/src/Response.php:149
#3 /var/www/vendor/async-aws/core/src/Result.php:69
#4 /var/www/vendor/symfony/amazon-sqs-messenger/Transport/Connection.php:234
#5 /var/www/vendor/symfony/amazon-sqs-messenger/Transport/Connection.php:374
#6 /var/www/vendor/symfony/amazon-sqs-messenger/Transport/Connection.php:80

As stacktrace shows, all this is triggered when resetting the connection, but it looks like the issue lies in how the response is resolved by async-aws/core.

[joricksteenstra]

We're experiencing the same issue, did you by any chance have a work around?

[victor-upmeet]

Actually no. We just filter out these errors so we don't get unnecessary alerts when they are encountered. We have several symfony messenger consumers who stop every hour, so we have this error a few times a day as it is sometimes triggered, but not always, when consumer is stopped.

[mrblur]

This hit us hard as every consumed message ends up with this exception and killed consumer.
We use elasticmq on local development and onpremise installations. On 2.1.0 consumers are working fine, maybe this would help to pin the issue.

[kemo]

This issue is still present in Symfony 7.2