When an error in the worker happens before the message is dispatched on the bus (deserialization error of a message for example), the message is neither ack, nor nack, the exception not caught and the worker quit.
The result is that the message stays in the queue (at the front). So the next worker will try to receive the same message again and likely fail again. This continues forever and you can't consume any good messages anymore.

A similar situation can happen when the handling of a message takes longer than the rabbitmq connection heartbeat or timeout. Ref. #31707 and php-enqueue/enqueue-dev#658 (comment)

Rabbitmq puts the messages back into the queue with a Redelivered header. How we solved it in our apps using https://github.com/M6Web/AmqpBundle is to ack the message directly when it has the Redelivered header and then trigger a retry.

I think it's important that SF messenger can handle those cases as well using it's retry logic and failed messages transport.