Skip to content

[Messenger] Remove non-sendable stamps before calling the serializer's encode method #45098

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: 7.4
Choose a base branch
from

Conversation

ntavelis
Copy link

@ntavelis ntavelis commented Jan 20, 2022

Q A
Branch? 6.1
Bug fix? no
New feature? yes
Deprecations? no
Tickets No
License MIT
Doc PR N/A

TL;DR; Instead of relying to each implementation of the SeirializerInterface to remove the non-sendable stamps from the envelope, we do it before calling the encode method, to make sure they are not send into the transport(even for a user's custom serializer)


Hello, I came across an issue when having a custom php serializer, I was calling PHP's serialize method on the envelope. But serialization was failing with error Serialization of 'Closure' is not allowed.

The issue was that I was trying to serialize the recently added \Symfony\Component\Messenger\Stamp\AckStamp, this class accepts a closure in the constructor and such a class can not be serialized form PHP's native serialize method. It turns out that this class should not be serialized and we should remove the stamps that implement the interface \Symfony\Component\Messenger\Stamp\NonSendableStampInterface by doing that before serializing the message:

$envelope = $envelope->withoutStampsOfType(NonSendableStampInterface::class);

Both of messenger's serializers \Symfony\Component\Messenger\Transport\Serialization\PhpSerializer and \Symfony\Component\Messenger\Transport\Serialization\Serializer make the above call to withoutStampsOfType before serializing an envelope.

Which got me thinking that it would have been nice if messenger was removing the stamps that implement \Symfony\Component\Messenger\Stamp\NonSendableStampInterface before passing the envelope to be encoded to the given serializer. My solution was to create a SerializerDecorator that removes the stamps and calls the serializer that has been provided to the given transport.

This solution makes the behavior consistent with native messenger's serializers and the custom serializers of the users. If a user calls withoutStampsOfType method on its own implementation there will be no error, so no BC break.

Thank you

@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.1 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@ntavelis ntavelis force-pushed the decorator_serializer branch from 327cfa9 to 3ec3a86 Compare January 20, 2022 23:14
…ndableStampInterface because we remove it explicitly in the serializer and will not be send to the transport
@carsonbot
Copy link

Hey!

I think @nikophil has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

@fabpot fabpot modified the milestones: 6.1, 6.2 May 20, 2022
@nicolas-grekas nicolas-grekas modified the milestones: 6.2, 6.3 Nov 5, 2022
@nicolas-grekas nicolas-grekas modified the milestones: 6.3, 6.4 May 23, 2023
@nicolas-grekas nicolas-grekas modified the milestones: 6.4, 7.1 Nov 15, 2023
@xabbuh xabbuh modified the milestones: 7.1, 7.2 May 15, 2024
@fabpot fabpot modified the milestones: 7.2, 7.3 Nov 20, 2024
@fabpot fabpot modified the milestones: 7.3, 7.4 May 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants