Did you see#39622 ?

But indeed we can merge this one too

Hi@lyrixx

I wasn't aware of this other PR - but I think they don't conflict with each other

Shouldn't exceptions thrown by your custom normalizers implementSymfony\Component\Serializer\Exception\ExceptionInterface?

yes@dunglas but if any error that the developer didn't think about occurs in this normalizer, it will result in the message indefinitely requeued, and the worker will be in error until the message has not been manually removed from the queue.

I think that ensuring that the proper exception is thrown is the responsibility of the normalizer implementation and I fear that doing this in core would lead to confusing situations more than it would help.
Is there a use case where such uncaught exception cannot be quickly spotted in dev (and the normalizer be fixed accordingly)?

typically some broken json/xml where some fields are missing that are passed to rabbit, that will cause aTypeError inside the normalizer
I mean, sometimes you cannot prevent some type error to occur, moreover if you deserialize some input from another app, and presently if this occurs in a custom normalizer the workers will be down until the message is manually removed from the queue

Something "classic":

1. You have a class "Foo"
2. There are messages in the queue
3. You rename it to "Bar"
4. You deploy
5. The consumer try to deserialize "Foo"
6. 💥

You have to do some weird things to deal with that! (I really need to finish my PR BTW)

Can't the failing queue be used for that?https://symfonycasts.com/screencast/messenger/show-retry-failures

No because the exception breaks everything and is out of the scope. But yes! it should be. I asked to my employer some time to work on this topic ASAP.

You fixed it@lyrixx right? Only in 6.2 though?

I'm not sure I covered this case.

@nikophil Can you revise this PR and check if you still need it?