Hello,

here is a proposal for Messenger, in order to improve processing for messages incoming into the app (ie: messages produced by another app) and messages outgoing from the app (ie: messages produced by our app but intended to be consumed by other apps).

Problem with incoming messages: (see#49094)

If messages are incoming in the app under different formats (json, xml, whatever) there is no easy way to customizeper transport in which format the transport will deserialize the message. Same problem occurs for serialization context. Another annoyance is that we need to create a custom serializer class to determine in which class we want to deserialize the message.

This PR proposes a new configuration to handle this:

messenger:transports:transport_for_incoming_messages:dsn:'null://'# when used, will use a new class "IncomingMessageSerializer", along with Symfony's serializerincoming_message_serializer:# one of these are required:messageClass:App\Some\MessagemessageClassResolver:'service_id'# should implement a new interface "IncomingMessageClassResolverInterface"format:'json'# defaults on "messenger.serializer.symfony_serializer.format"context:{some: context}# if empty, defaults on "messenger.serializer.symfony_serializer.context"# this option could be useful when dealing with complex messages which needs specific serializer serviceserializer:'my_fancy_serializer'# defaults on "@serializer"

Problem with outgoing messages: (see#49081)

Messages which are made to be processed by other apps should be sanitized: stamps and headertype must be removed, otherwise they could create errors in other apps (ie: if the message class does not have the same FQCN in both apps, or if the bus' name in sender app does not exist in receiver app: both of these cases will trigger errors when processing messages in the receiver app).
Outgoing messages may also be required to have specific format/context, so we must be able to configure format, context and serializer service used.

messenger:transports:transport_for_outgoing_messages:dsn:'null://'# when used, will use a new class "OutgoingMessageSerializer", along with Symfony's serializer# all parameters are optionaloutgoing_message_serializer:format:'json'# defaults on "messenger.serializer.symfony_serializer.format"context:{some: context}# if empty, defaults on "messenger.serializer.symfony_serializer.context"serializer:'my_fancy_serializer'# defaults on "@serializer"

IMHO, both of these cases are such common, that they should not require boilerplate in userland.

At the end, the PR also provides the ability to add serialization context/format/service per transport, for all other cases:

messenger:transports:my_transport:dsn:'null://'# short notation "serializer: custom_transport_serializer" still worksserializer:# if one of these options are provided,# the transport will use "\Symfony\Component\Messenger\Transport\Serialization\Serializer"format:'json'# defaults on "messenger.serializer.symfony_serializer.format"context:{some: context}# if empty, defaults on "messenger.serializer.symfony_serializer.context"serializer:'my_fancy_serializer'# defaults on "@serializer"# previous options are incompatible with the followingserializer_id:custom_transport_serializer

Optionsincoming_message_serializer,outgoing_message_serializer andserializer are incompatible

Another solution for the problem would have been to keep only oneserializer option, along with atype option (normal|incoming|outgoing|custom). But the allowed underlying options and behavior really differ from one type to another, that I preferred using 3 different options.