Hmm, I’ve actually not seen this behavior - we even illustrate the correct behavior on our SymfonyCasts screencast.

There IS a bug (and PR) where the failed message IS sent back to the failure transport successsfully, but the error details are lost. Is it possible the message IS sent back to the failure transport (it will have a different id now) but that you don’t recognize it due to the missing/different error on that message?

This is a screenshot with the error thrown during retry.

This looks like a serialization error. In this case it's meant to be dropped. Please investigate why serialization fails after manual retry.

@Tobion Yes that's it.

With the default php serialization there is no problem, but the problem occurs when we add in the file messenger.yaml this configuration :

  messenger:
    serializer:
      default_serializer: messenger.transport.symfony_serializer
      symfony_serializer:
        format: json
        context: { }

We are trying to find a solution at this problem.

@ke20 Quickly looking at the Symfony\Component\Debug\Exception\FlattenException class, it seems that in some cases non-serializable instances could be created (and that seems to correspond to the error you get):

• An instance is created with new FlattenException()
• During serialization getHeaders() returns null as the $headers property is not initialized
• Unserialization fails as setHeaders() only accepts an array argument and not null

Could you change the declaration of the $headers property of FlattenException to private $headers = [] and see if that fixes your problem ? (You'll have to re-test from the beginning as instances that were serialized before you apply the fix are invalid for good).

@skalpa I've made the modification on the class FlattenException like you have suggered me.

I confirm you that the problem has been fixed with this modification.

I've succeed to relaunch many time my message in error with the command bin/console messenger:failed:retry <id>.

We experienced the same problem. Would be good to have fix for it introduced.

Yea, that issue makes sense - if you ran new FlattenException()... then you would create an object that will not be serialized/deserialized correctly when using the Symfony serializer.

But, question - how/where are you calling new FlattenException()? The core code calls the correct FlattenException::createFromThrowable()

I had the same problem too. I created a project to show the problem https://github.com/tienvx/symfony-failed-message-reproduction.

Here is the PR to fix it #33600

To make this issue clear, I will list 2 problems I can see in this issue:

1. the failed message IS sent back to the failure transport successsfully, but the error details are lost
2. The serialization with headers

My PR fix 1, not 2.

@Tobion I also think that getHeaders should never return null as setHeaders does have an array type-hint.

I'll work on fixes for both FlattenException versions tonight (the one from Debug and the one from ErrorRenderer).

@skalpa To really close this issue, I think we would need your PR on getHeaders, right?

@fabpot Yes, the PR you merged fixes a related issue but not the one described here afaik, so I guess it should be re-opened.
Mine is actually ready, I should be able to submit it soon.

I submitted #33630 to fix this, however I couldn't find a way to do it without breaking BC, as more methods had a similar problem (i.e: setPrevious and setTrace) that couldn't get solved by setting a default property value as discussed for setHeaders, so I don't know if my solution is valid.

As I don't really fancy the BC, I tried to find better solutions and the only alternate fixes that come to my mind would be to:

• Modify messenger so it doesn't use the FlattenException from the Debug component at all
• Or add a FlattenException denormalizer (my preferred one atm)

Strictly speaking, both would also break BC, but as messenger is still experimental it might be more acceptable.

Now I think I understand the confusion between this issue and #32311:

• @fabpot and I do not aware that [Messenger] Messages retried on failure transport lose exception metadata #32311 exists before. Sorry guys!
• What is message is dropped in the issue's description really mean?
  • If the failed message itself (mean when I run the command messenger:failed:show it return 0 messages) => sorry guys, my bad. I should have linked my PR [Messenger] Fix exception message of failed message is dropped on retry #33600 to [Messenger] Messages retried on failure transport lose exception metadata #32311, not this issue. Sorry again! (btw, like @weaverryan I have not seen this behavior)
  • If the error message of the failed message (mean messenger:failed:show return 1) => I think this issue is duplicated with [Messenger] Messages retried on failure transport lose exception metadata #32311 (and my PR [Messenger] Fix exception message of failed message is dropped on retry #33600 fixed that issue)

@tienvx Here the entire message is dropped, as the Serializer component is unable to deserialize the message.

Not everyone may be affected, as it only happens when using the component as the messenger serializer, which is not the default, and has to be configured as described in #32719 (comment).

In our project we faced this issue exactly in case of using symfony serializer instead of default one.

Hello guys.
What the status for this issue? Are you still planning fix this?

I think #33650 addresses this, but it may need to be updated now that the FlattenException is in a different component.