-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] No need for retry to require SentStamp #32053
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
Merged
Tobion
merged 1 commit into
symfony:4.3
from
Tobion:no-need-for-retry-to-require-sentstamp
Jun 24, 2019
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The edge case I believe I was coding for (and maybe we decide it's not legitimate) is if you send on transport/sender A but receive on transport/receiver B. It's an odd case, but in that situation, we would (I think?) want to re-send to sender A, not receiver B. Thoughts?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory you could receive a message from transport B but route it to transport A for sending.
But in the end, senders and receivers are bound together by TransportInterface which requires implementing both. So if you do the above, you still have to implement sending part in transport B. So you could just use the same sender in transport B that you use in transport A if you need to cover retry going to transport A.
So to me that is an edge case that people can solve in custom transports. Nothing we should take care of by default. And in case we want to account for this later, the better and more explicit solution to me is to add a config option on the transport to configure the
retry_transport
(similar to thefailure_transport
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also don't see how SentStamp should work for this case anyway. If a message comes from transport B, it cannot have the SentStamp pointing to transport A. If it was sent to transport B, it also has the SentStamp pointing to B (at least the last SentStamp) added by SendMessageMiddleware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would work like this:
A) Send a message on TransportA. The message now has a SentStamp for TransportA.
B) Receive message on TransportB. The message will, of course, still only have the
SentStamp
for TransportA.It's an edge case where, for example, you're using AMQP and send to TransportA, which has some routing & binding keys that ultimately put it in some queue "foo". Then, for whatever reason, you setup TransportB to receive from queue "foo". In this case, you will directly "receive" a message from TransportB that only has a SentStamp for TransportA.
I think that's not true... at least on a low, component level. I believe that, when routing, you can set the class to route to any service id that has the
SenderInterface
, even if it's not defined as a transport (and doesn't define aTransportInterface
). I think the same is true for receiving messages: I think you can pass any service id tomessenger:consume
.Sorry to complicate things - this is what "possible" situation that was floating around when this was originally coded.
The tl;dr is this: the
SentStamp
is the concrete way to mark exactly which sender sent a message so that we can definitely use the same sender during redelivery. But yes, we could add aretry_transport
option, which could act as an override for SentStamp/be used when that stamp is not available. Or, if the stamp is not available, we could "try" to redeliver to the "receiver" (and throw an exception if it doesn't implementSenderInterface
).Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to not have the SentStamp logic. We agreed it tries to solve an edge case. To me that is something SF Messenger should not code against. It potentially breaks as much as it solves. For example, if I sent a Message to transport A, rename the transport to B and deploy again. Suddenly the retry of all existing messages in the queue breaks because it still tries to resend to A but A does not exist anymore. And with delayed messages of hours or days, this can easily happen.
How do we proceed now?
I'm in favor of 1).
2) would make the messenger behavior context dependent which I don't like at all.