I've no idea. Let's keep open. Maybe someone else could help.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Given this is the only hit when searching for this error message, I wanted to add my findings, although I encountered this with Symfony Messenger rather than Enqueue.
Long story short, I haven't found a fix, the only way I was able to work around it is giving a time limit of 5 minutes to the worker – and restarting it over and over… When it runs long, the connection eventually lost, and the next attempt to touch rabbit fails with the above.
I do wonder if it only happens with AWS RabbitMQ and PHP, given the lack of complaints on the intertubes.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

I have similar problem. One of my workers kept dying from time to time on a non-ssl connection with message: "Library error: connection closed unexpectedly". After migrating to AWS RabbitMQ (which uses SSL) this keeps happening and I get instead "Library error: a SSL error occurred". That would've meant that the old error message is now obscured by the new one.

Did you managed to solve your issue @TamasSzigeti ?

@jkobus try cloudamqp instead. they disable heartbeat and use tcp timeout instead and we dont have this issue. something you can't do in aws rabbitmq. we still trying to find a solution for AWS since its cheaper to maintain.

Same here, no solution with AWS, we have literally just migrated to CloudAMQP a couple days ago.

Guys, I assume you were using AWS MessageMQ (RabbitMQ) in a cluster deployment setup.
The problem is, that:

For each TCP request that a client makes through a Network Load Balancer, the state of that connection is tracked. If no data is sent through the connection by either the client or target for longer than the idle timeout, the connection is closed. If a client or a target sends data after the idle timeout period elapses, it receives a TCP RST packet to indicate that the connection is no longer valid.

Elastic Load Balancing sets the idle timeout value for TCP flows to 350 seconds. You cannot modify this value. Clients or targets can use TCP keepalive packets to reset the idle timeout. Keepalive packets sent to maintain TLS connections cannot contain data or payload.

source

The TCP RST packet causes the Library error: a SSL error occurred (i just reproduced that using [email protected]) and probably also Library error: connection closed unexpectedly on a non-SSL setups using custom RabbitMQ behind an AWS Network load balancer.

So, the solution would be to: don't stay idle for longer than 350 seconds after opening a connection to a cluster.

Fun-fact: the connection on the RabbitMQ by default stays open for about an hour.

As for heartbeat - if you were using non blocking calls, heartbeat is not working. At least not in php-amqp.:

heartbeats are limited to blocking calls only, so if there are no any operations on a connection or no active consumer set, connection may be closed by the broker as dead.

It seems like a solution for now would be to automatically recover from network failures, but that option is not available in Symfony Messenger (yet) which I'm using.

Hope that helps!

It might be a solution https://github.com/php-enqueue/enqueue-dev/blob/master/docs/transport/amqp_lib.md#long-running-task-and-heartbeat-and-timeouts