Symfony version(s) affected

6.0.3

Description

After the 4th or 5th retry the ErrorDetailsStamp header of a message that was sent back to the queue using the RecoverableMessageHandlingException grows to 60k and RabbitMQ rejects the message with the error

Library error: table too large for buffer

I did find a related and merged issue (#34082) but this does not seem to have solved it, there are recent comments from people who ran into the same issue.

I am able to solve this in using a custom serializer that removes the ErrorDetailsStamp but I think that this is not expected behaviour.

This also has implications for the other transports like Doctrine where very large entries for simple messages are being inserted into the databae.

How to reproduce

Just create a TestMessage and watch the ErrorDetailsStamp header grow out of proportion:

final class TestMessageHandler .....

public function __invoke(TestMessage $message): int
{
  throw new RecoverableMessageHandlingException('Recovered at '.time());
}

Possible Solution

Create a custom serializer and remove the ErrorDetailsStamp in the encode method:

class WorkaroundSerializer ...

public function encode(Envelope $envelope): array
{
.....
  $filteredStamps = [];
  $envelopeStamps = $envelope->all();

  foreach ($envelopeStamps as $stamps) {
    foreach ($stamps as $stamp) {
      if (!$stamp instanceof ErrorDetailsStamp) {
        $filteredStamps[] = $stamp;
      }
     }
   }

  return ... 
}

I guess another solution is to not even add the ErrorDetailsStamp to a user initiated recoverable message as it is not really an error but intended behaviour? Or make headers configurable, eg traceCount: 1 to only add the latest trace or none with 0?

Does it make logical sense that this is an Exception and not a stamp? With it being an Exception although not being an error it also has to be removed from monitoring tools (Sentry etc.) to not be a false negative.

Additional Context

No response