Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Messenger] Add HeaderStamp to add custom headers #34481

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

[Messenger] Add HeaderStamp to add custom headers #34481

wants to merge 1 commit into from

Conversation

alanpoulain
Copy link
Contributor

@alanpoulain alanpoulain commented Nov 21, 2019 •
edited
Loading

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

Add a HeaderStamp to add custom headers to an encoded message to be used by the transport.

It's a proposal, maybe there is a better way to do this.

This feature would be useful in my case where I need to add a custom header to deduplicate the messages in an AMQP context. This is the RabbitMQ plugin I would like to use: https://github.com/noxdafox/rabbitmq-message-deduplication.

An example of how to use it:

$bus->dispatch(
    (new Envelope($message))->with(new HeaderStamp('x-deduplication-header', $dataUsedToDeduplicateMessages))
);

@alanpoulain alanpoulain requested a review from sroze as a code owner November 21, 2019 10:34
@alanpoulain alanpoulain force-pushed the messenger-header-stamp branch from f38b636 to f70e466 Compare November 21, 2019 10:35
@nicolas-grekas nicolas-grekas added this to the next milestone Nov 24, 2019
@javiereguiluz
Copy link
Member

@alanpoulain thanks for this contribution and for explaining it in the description of your PR. To allow us better evaluate this (and document it, if merged) could you please add a simple example of this feature in action? Thanks.

@alanpoulain alanpoulain force-pushed the messenger-header-stamp branch from f70e466 to 39bd4e3 Compare December 24, 2019 14:48
@alanpoulain
Copy link
Contributor Author

@javiereguiluz sorry for the delay! Rebased and example added in the description of this PR.

@alanpoulain
Copy link
Contributor Author

Any input about this PR?

Nyholm
Nyholm reviewed Jan 19, 2020
View reviewed changes
Copy link
Member

@Nyholm Nyholm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also deserialize the header stamp, right?
How do we handle message requeue? Should stamps be removed and re-added by a potential second transport?

I know I been speaking with @weaverryan about this. I was in favour of introducing a generic stamp, but Im not sure if Ryan chose to not do it because of a reason or just because there were not obvious use case for it at the time.

@alanpoulain
Copy link
Contributor Author

Is there an issue with the (de)serialization of this stamp? It seems to me there would be no issue.
For the requeue it seems to be the stamps are kept by default, doesn't it?

@Nyholm
Copy link
Member

Nyholm commented Jan 20, 2020

Will the stamp be present when I get the message back from the queue?
Oh silly me, I was expecting you to need to modify decodeStamp.

————

If I put a message on transport A. It uses some headers Foo. Then I consume the message, it fails and goes to the failure transport B. Will it still have the same headers Foo? Should it have the same headers or should headers be cleared?

Could you please elaborate how it will work?

@alanpoulain
Copy link
Contributor Author

alanpoulain commented Jan 20, 2020 •
edited
Loading

For the second question, currently since the stamp is kept (and serialized), the headers will be kept too.

If we use the NonSendableStampInterface for this stamp, then the headers will be cleared if the sending of the message fails (since the header stamp will not be serialized).

I don't see why the headers should be cleared, but if there are some use cases maybe we could introduce another stamp (like a NonSendableHeaderStamp, implementing the NonSendableStampInterface).

Also I see I've not modified the PhpSerializer, I think it should be modified too, doesn't it?

Tobion
Tobion suggested changes Jan 20, 2020
View reviewed changes
Copy link
Contributor

@Tobion Tobion left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is necessary. Adding custom headers to AMQP is already possible by using the AmqpStamp AmqpStamp::createWithAttributes(['headers' => [ ... ]). For other transports, adding custom headers is possible by decorating the serializer and returning the custom headers there.
Your solution will duplicate the headers both as serialized data and as headers in the transport.

@alanpoulain
Copy link
Contributor Author

I didn't see the possibility of using the AmqpStamp for this 👍

For the other transports, if the stamp implements NonSendableStampInterface it shouldn't be serialized, right?
But then it would disappear when being requeued, as @Nyholm pointed out.

Feel free to close this PR if this use case is not needed.

@mleczakm
Copy link
Contributor

@Tobion with current implementation of amqp sender overriding already existing header entries (like type, which is for no reason hardcoded to message FQCN) is impossible...

@mleczakm mleczakm mentioned this pull request Jan 22, 2020
Closed
@Nyholm
Copy link
Member

Nyholm commented Jan 26, 2020

I guess AmqpStamp is the reson we never needed a GenericHeaderStamp.

@alanpoulain, Im happy to close this if AmqpStamp solves your problem.

@Tobion Tobion closed this Jan 26, 2020
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.1 May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Nyholm Nyholm Nyholm left review comments

@Tobion Tobion Tobion requested changes

@sroze sroze Awaiting requested review from sroze

Assignees
No one assigned
Labels
Feature Messenger Status: Needs Work
Projects
None yet
Milestone
5.1
Development

Successfully merging this pull request may close these issues.
7 participants
@alanpoulain @javiereguiluz @Nyholm @mleczakm @Tobion @nicolas-grekas @carsonbot