Thanks to visit codestin.com
Credit goes to github.com

Skip to content

feat(exchange): treat various ssl and tcp errors as AMQPConnectionException#571

Merged
lstrojny merged 1 commit into
php-amqp:latestfrom
tunterreitmeier:feat/publish-connection-exception
Feb 4, 2026
Merged

feat(exchange): treat various ssl and tcp errors as AMQPConnectionException#571
lstrojny merged 1 commit into
php-amqp:latestfrom
tunterreitmeier:feat/publish-connection-exception

Conversation

@tunterreitmeier
Copy link
Copy Markdown
Contributor

This tries to fix symfony/symfony/issues/48241

The specific issue is that e.g. the AWS Load Balancer closes idle connections after a certain time. Long running tasks will then run into the issue of a lost connection.
symfony/symfony/pull/54167 already provides an adequate solution by simply trying to reconnect. However, the fix specifically catches AMQPConnectionException, while the actual exception thrown is the less specific AMQPException.
This can also be seen in the original issue:

(AMQPException): Library error: a SSL error occurred

My first instinct was to catch the less specific Exception instead, which would solve the issue.
symfony/amqp-messenger@6.4...wikando:amqp-messenger:6.4-retry
But I think there is a fair argument to be made, that this indeed is an Exception relating to the connection. That's where this PR is coming from.
I tried coming up with a test, but I'm at a loss how to recreate this specific scenario (connection closed by server). Feedback is obviously welcome.

I really hope that helps. Thanks a bunch!

@lstrojny
Copy link
Copy Markdown
Collaborator

lstrojny commented Jan 6, 2026

Could you rebase?

@tunterreitmeier
Copy link
Copy Markdown
Contributor Author

done - thanks for looking into this

@lstrojny
Copy link
Copy Markdown
Collaborator

lstrojny commented Jan 8, 2026

Looks like we have failures for librabbitmq <= 0.13. You probably need to add a preprocessor conditional based on AMQP_VERSION

@tunterreitmeier
Copy link
Copy Markdown
Contributor Author

It's been a while since I checked librabbitmq, but yeah two consts are not defined in older versions.
Was able to build and test with v.010.0

@lstrojny
Copy link
Copy Markdown
Collaborator

I would have a relatively strong preference of not checking for the literal constants but instead for the AMQP_VERSION (see https://github.com/alanxz/rabbitmq-c/blob/8b7471eab8d09536b3c104dbb30a65699cf48104/include/rabbitmq-c/amqp.h#L157 and packing macro in https://github.com/alanxz/rabbitmq-c/blob/8b7471eab8d09536b3c104dbb30a65699cf48104/include/rabbitmq-c/amqp.h#L136). That way, when we remove support for older librabbitmq versions it is very clear which conditions can be retired. Because I know that otherwise these ifdefs will linger around forever – because I will totally forget.

@tunterreitmeier
Copy link
Copy Markdown
Contributor Author

Totally makes sense. The check now uses AMQP_VERSION

@tunterreitmeier
Copy link
Copy Markdown
Contributor Author

@lstrojny can you retry the single failing pipeline? I feel like it is just some flakyness in the setup-php action

@lstrojny lstrojny merged commit 89bf8b9 into php-amqp:latest Feb 4, 2026
176 of 177 checks passed
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.

[Messenger] Issues after migrating to AWS RabbitMQ

2 participants