-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] fix retry of messages losing the routing key and properties #34134
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -47,20 +47,22 @@ public function send(Envelope $envelope): Envelope | |
$delayStamp = $envelope->last(DelayStamp::class); | ||
$delay = $delayStamp ? $delayStamp->getDelay() : 0; | ||
|
||
/** @var AmqpStamp|null $amqpStamp */ | ||
$amqpStamp = $envelope->last(AmqpStamp::class); | ||
if (isset($encodedMessage['headers']['Content-Type'])) { | ||
$contentType = $encodedMessage['headers']['Content-Type']; | ||
unset($encodedMessage['headers']['Content-Type']); | ||
|
||
$attributes = $amqpStamp ? $amqpStamp->getAttributes() : []; | ||
|
||
if (!isset($attributes['content_type'])) { | ||
$attributes['content_type'] = $contentType; | ||
|
||
$amqpStamp = new AmqpStamp($amqpStamp ? $amqpStamp->getRoutingKey() : null, $amqpStamp ? $amqpStamp->getFlags() : AMQP_NOPARAM, $attributes); | ||
if (!$amqpStamp || !isset($amqpStamp->getAttributes()['content_type'])) { | ||
$amqpStamp = AmqpStamp::createWithAttributes(['content_type' => $contentType], $amqpStamp); | ||
} | ||
} | ||
|
||
$amqpReceivedStamp = $envelope->last(AmqpReceivedStamp::class); | ||
if ($amqpReceivedStamp instanceof AmqpReceivedStamp) { | ||
$amqpStamp = AmqpStamp::createFromAmqpEnvelope($amqpReceivedStamp->getAmqpEnvelope(), $amqpStamp); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Will this work when it's being sent to the failure transport... and the failure transport is a direct AMQP exchange that relies on the I think flow would be: A) Message is received for last retry If I'm correct, on a high level, it seems like we want to do this trick unless we detect that the message is being sent through a different transport than it was originally sent through.... or maybe the "failure transport" is added as an edge-case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes the flow would not work. But again, it would lose the original routing key in the failure transport which this PR tries to solve. So retrying from the failure transport might not work if the routing key is different suddenly. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What you described is also what is described in #32994 but the problem is that the failed transport should not need to be direct. I'll answer there. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Documenting that a failure transport should not be direct is a valid solution I think. But:
I don't think I understand what you're saying here. Assuming we successfully deliver a message to the routing transport (by setting the routing key correctly for the situation), what problem would the routing key being different cause? At that point, the routing key isn't used anymore: the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. People could use the routing key using the AmqpReceivedStamp in their handler to make decisions. But again all these things are edge cases I would not worry about unless you have a certain change request in mind? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, the options are:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Honestly there is nothing to document or fix here. Your case is just one of endless configuration possibilities. I can also configure the failure transport with the appropriate binding keys and voila it still works with the original routing keys. We shouldn't enforce or document a random edge case here that does not apply always. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What this PR is about is publishing retry/failure with the same routing key and priority etc as the original message. And this is absolutely the right and logical thing to do because retry message should be the same as the original ones. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The default is a fanout exchange. So we're covering 99% of all cases. If someone changes it to a direct exchange for failure, it's not the messenger job to interfere with this and make certain assumptions. |
||
} | ||
|
||
try { | ||
$this->connection->publish( | ||
$encodedMessage['body'], | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -225,7 +225,7 @@ private function publishWithDelay(string $body, array $headers, int $delay, Amqp | |
private function publishOnExchange(\AMQPExchange $exchange, string $body, string $routingKey = null, array $headers = [], AmqpStamp $amqpStamp = null) | ||
{ | ||
$attributes = $amqpStamp ? $amqpStamp->getAttributes() : []; | ||
$attributes['headers'] = array_merge($headers, $attributes['headers'] ?? []); | ||
$attributes['headers'] = array_merge($attributes['headers'] ?? [], $headers); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This looks subjective either way (or am I missing something)? The There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This just gives headers from the serialization more prio than headers from the stamp. As the headers from the stamp are copied for retry, this just makes more sense now (in case re-serialization returns different headers). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was huge BC break, it broke our app and make overriding |
||
|
||
$exchange->publish( | ||
$body, | ||
|
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.
This feels like the opposite of the merging logic in
Connection::publishOnExchnage()
. In that method,headers
from the serializer win over headers from theAmqpStamp
. But here, we're saying: "only use theContent-Type
from the serializer if it is NOT already set onAmqpStamp
(i.e.AmqpStamp
wins)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.
If people set the content-type manually on the envelope, we don't want to overwrite this. THis is how it has been before already.