[Messenger] Uses Symfony Serializer by default for envelope items #28270
Conversation
0fc495d to
a67fe63
Compare
| @@ -22,12 +22,14 @@ class Serializer implements DecoderInterface, EncoderInterface | |||
| private $serializer; | |||
| private $format; | |||
| private $context; | |||
| private $envelopeWithSerialize; | |||
There was a problem hiding this comment.
encodeUsingPhpSerialize? (see other comment about "decode")
|
|
||
| private function decodeEnvelopeItems($encodedEnvelope) | ||
| { | ||
| if ($this->envelopeWithSerialize) { |
There was a problem hiding this comment.
should this flag be set? isn't isset($encodedEnvelope['headers']['X-Message-Envelope-Items']) enough?
There was a problem hiding this comment.
You are right, it would be better 👌
a67fe63 to
b6fd7af
Compare
|
Rational in original PR was that envelop items are a thing specific to the Symfony Messenger component in order to configure transport & middleware and would not be used by third party systems. So there is no interop required (or that would mean 3rd party systems would have to implement features the same way Symfony Messenger does. Not likely to happen IMHO). Mentioned use-case in #28270 is about adding headers to the transport layer. Hence this is the transport responsibility. Using directly envelop items for this and relying on the fact those are serialized in |
That I don't agree with: even if the envelopes provided by the core are not necessarily aimed to be shared across systems, I don't see why we would enforce their serialization to be obfuscated with PHP's There is another aspect to it: JSON is much better for backward compatibility. BC is pretty important for anything that is asynchronous (because you can't wait for all the messages to be processed when you deploy the workers) and this is this main reason that I believe we should use Symfony Serializer for this.
I definitely do agree with this though: we should add an envelope which could be named MessageHeaderEnvelope that is understood by the |
b6fd7af to
319df2b
Compare
|
👍 for using plain JSON via Symfony Serializer (we are moving away from PHP serializer anyway). |
|
@sroze Can you finish this PR? |
319df2b to
9b575ab
Compare
|
@fabpot what a nice timing. Just pushed the rebased and updated version without the |
|
Thank you @sroze. |
…elope items (sroze) This PR was merged into the 4.2-dev branch. Discussion ---------- [Messenger] Uses Symfony Serializer by default for envelope items | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | yes | Deprecations? | no | Tests pass? | yes | Fixed tickets | #28164 | License | MIT | Doc PR | ø The original approach was to use `serialize`/`unserialize` for envelope items. It turns out it has limitations (see #28247) and reduces the compatibility with 3rd party systems (see #28164). This pull-request changes the existing mechanism by using Symfony Serializer by default. It keeps the `serialize`/`unserialize` mechanism to allow users of the experimental component to keep using it in 4.2 and allow to have a non-disruptive upgrade to 4.2. Commits ------- 9b575ab Uses Symfony Serializer by default for envelope items
|
I've created symfony/symfony-docs#10276 to document this new feature. Please, don't forget to create a doc issue for every new feature. Also, we have lots of pending issues related to Messenger in the Symfony Docs. We really need your help 🙏 Thanks! |
The original approach was to use
serialize/unserializefor envelope items. It turns out it has limitations (see #28247) and reduces the compatibility with 3rd party systems (see #28164). This pull-request changes the existing mechanism by using Symfony Serializer by default.It keeps the
serialize/unserializemechanism to allow users of the experimental component to keep using it in 4.2 and allow to have a non-disruptive upgrade to 4.2.