Benoit GALATI

Should it target version `5.4` actually?

@nicolas-grekas I think it should have been handled since the beginning because it's an unserialization issue that currently ends with generic kind of exception instead of `MessageDecodingFailedException`. I think I...

Any chance to get some new feedbacks based on my last comment before rebasing?

@nicolas-grekas @OskarStark thanks for the review, It's ready for 5.4 :+1: Let me know for any other updates that should be performed.

Thank @nicolas-grekas! BTW, I think we could prevent message losses upon `MessageDecodingFailedException` by requeuing the message in the configured `failed_queue`. We could even configure a dedicated queue. That could be...

@lyrixx I read what you did and from what I understand it would still be possible to lose messages upon other unserialization issues. For example, a field has been renamed...

Thanks for the feedback. If we can do something simpler that handles every cases it would be great though. What do you think about what I proposed? Simply wrapping the...

@alex-dev ~~I checked out your branch but it does not work for my case where I have a class not found for the `Message` of the `Envelop`. I will dig...

@alex-dev It works actually, I was serializing this thing the wrong way :+1: Thanks!

@alex-dev @lyrixx I have a PoC in preparation that proposes to add a new configuration option in Messenger: ```yaml framework: messenger: failure_message_decoding_transport: failed ``` What do you think about such...