Sorry for being late on#33600 stuff!

Summary:

A) We should merge this and revert#33600 (into 4.3)
B) We should merge#32341, which is a superficial fix in how the exception info is displayed in the command (into 4.3)
C) We should consider#32904 for the future, which is a safer way to try to store some exception info foreach time it fails. (4.4 or 5.1 - I know 4.4 needs to get shipped)

Still got same problem here. I could reproduce it by simply adding following in the handler

        $exception = null;        for ($i = 0; $i < 10; $i++) {            $exception = new Exception('Exception', null, $exception);        }        throw $exception;

Then I got

In AmqpSender.php line 77:                                               Library error: table too large for buffer

@Tobion I can also confirm the bug still exists, can you re-check if it was really fixed please? Also is there a test which validates the bugfix?

symfony/messenger v5.3.10

Okay, for those who still gets the above error and uses RabbitMQ broker.

In short, the key is message's headers: atype header andstamps headers. If you don't provide or corrupt such headers, you'll get the growing message problem.

This helped me, hopefully this will help you.

1. Make sure your symfony and messenger bundle are of version >=5.4

2. If you send 'symfony' ('internal', not 'external') messages manually, by publishing messages via RabbitMQ interface, and consuming such messages in your app, you'll get the problem discussed here - because most probably you won't provide all needed headers. As a workaround, find a way to publish the message via your app (e.g. temporary modify your code) without consuming that message, then go to RabbitMQ UI and see what headers are provided in the message. Use these headers later on when sending messages manually (the main headers you'll probably need would be something like 'type' and 'X-Message-Stamp-Symfony\Component\Messenger\Stamp\BusNameStamp')

3. For external messages, in case you followed the official symfony instruction herehttps://symfonycasts.com/screencast/messenger/transport-serializer#codeblock-bca382fd36 - bad news, theinstruction is misleading, which is not a big of surprise. If you take a look at how the stamps and 'type' are actually decoded/encoded inSymfony\Component\Messenger\Transport\Serialization\Serializer - you'll be surprised how much it differs from the instruction, especially that there is a type of stamps which must not be sent on retry at all, of a NonSendableStampInterface. So, your custom serializer for external messages must extend from Symfony\Component\Messenger\Transport\Serialization\Serializer as a starting point.

In my case I got this error after an exception with way too long message. It was ServiceNotFoundException which listed all other services in a ServiceLocator instance which was several hundreds class names. This got into ErrorDetailsStamp which ended up way too large.

However I saw the same error once even after fixing that. I think it can grow too large simply from the exception traces in ErrorDetailsStamp.