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

Skip to content

[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

Merged
merged 1 commit into from
Nov 4, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -34,4 +34,40 @@ public function testFlagsAndAttributes()
$this->assertSame(AMQP_DURABLE, $stamp->getFlags());
$this->assertSame(['delivery_mode' => 'unknown'], $stamp->getAttributes());
}

public function testCreateFromAmqpEnvelope()
{
$amqpEnvelope = $this->createMock(\AMQPEnvelope::class);
$amqpEnvelope->method('getRoutingKey')->willReturn('routingkey');
$amqpEnvelope->method('getDeliveryMode')->willReturn(2);
$amqpEnvelope->method('getPriority')->willReturn(5);
$amqpEnvelope->method('getAppId')->willReturn('appid');

$stamp = AmqpStamp::createFromAmqpEnvelope($amqpEnvelope);

$this->assertSame($amqpEnvelope->getRoutingKey(), $stamp->getRoutingKey());
$this->assertSame($amqpEnvelope->getDeliveryMode(), $stamp->getAttributes()['delivery_mode']);
$this->assertSame($amqpEnvelope->getPriority(), $stamp->getAttributes()['priority']);
$this->assertSame($amqpEnvelope->getAppId(), $stamp->getAttributes()['app_id']);
$this->assertSame(AMQP_NOPARAM, $stamp->getFlags());
}

public function testCreateFromAmqpEnvelopeWithPreviousStamp()
{
$amqpEnvelope = $this->createMock(\AMQPEnvelope::class);
$amqpEnvelope->method('getRoutingKey')->willReturn('routingkey');
$amqpEnvelope->method('getDeliveryMode')->willReturn(2);
$amqpEnvelope->method('getPriority')->willReturn(5);
$amqpEnvelope->method('getAppId')->willReturn('appid');

$previousStamp = new AmqpStamp('otherroutingkey', AMQP_MANDATORY, ['priority' => 8]);

$stamp = AmqpStamp::createFromAmqpEnvelope($amqpEnvelope, $previousStamp);

$this->assertSame('otherroutingkey', $stamp->getRoutingKey());
$this->assertSame($amqpEnvelope->getDeliveryMode(), $stamp->getAttributes()['delivery_mode']);
$this->assertSame(8, $stamp->getAttributes()['priority']);
$this->assertSame($amqpEnvelope->getAppId(), $stamp->getAttributes()['app_id']);
$this->assertSame(AMQP_MANDATORY, $stamp->getFlags());
}
}
14 changes: 8 additions & 6 deletions src/Symfony/Component/Messenger/Transport/AmqpExt/AmqpSender.php
Original file line number Diff line number Diff line change
Expand Up @@ -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'])) {
Copy link
Member

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 the AmqpStamp. But here, we're saying: "only use the Content-Type from the serializer if it is NOT already set on AmqpStamp (i.e. AmqpStamp wins)

Copy link
Contributor Author

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.

$amqpStamp = AmqpStamp::createWithAttributes(['content_type' => $contentType], $amqpStamp);
}
}

$amqpReceivedStamp = $envelope->last(AmqpReceivedStamp::class);
if ($amqpReceivedStamp instanceof AmqpReceivedStamp) {
$amqpStamp = AmqpStamp::createFromAmqpEnvelope($amqpReceivedStamp->getAmqpEnvelope(), $amqpStamp);
Copy link
Member

Choose a reason for hiding this comment

The 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 default_publish_routing_key config to route to some "failure" queue?

I think flow would be:

A) Message is received for last retry
B) Message fails again and so is sent to the failure transport.
C) This code will see the routingKey from the original message (e.g. foo) and set it on the AmqpStamp
D) When this code is forwarded into Connection::publish() below, the routing key (foo) in AmqpStamp will be used instead of the default_publish_routing_key from the "failure transport".
E) Message will be sent once again with the foo routing key, instead of the one from the failure transport.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

Choose a reason for hiding this comment

The 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:

So retrying from the failure transport might not work if the routing key is different suddenly.

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 messenger:failed:retry command consumes from the failure transport and dispatches into the bus. If it failed again, then re-using the "last routing key" (what this PR does) would correctly send it back to the failure transport, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Member

Choose a reason for hiding this comment

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

Well, the options are:

  1. document not to use a direct transport as your failure transport.

  2. somehow add code here for the failure transport situation: like look for the RedeliveredToFailureTransportStamp... or something cleaner (not sure what). If there’s no reasonable way to do this, then option 1 becomes the only option.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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'],
Expand Down
29 changes: 29 additions & 0 deletions src/Symfony/Component/Messenger/Transport/AmqpExt/AmqpStamp.php
Original file line number Diff line number Diff line change
Expand Up @@ -46,4 +46,33 @@ public function getAttributes(): array
{
return $this->attributes;
}

public static function createFromAmqpEnvelope(\AMQPEnvelope $amqpEnvelope, self $previousStamp = null): self
{
$attr = $previousStamp->attributes ?? [];

$attr['headers'] = $attr['headers'] ?? $amqpEnvelope->getHeaders();
$attr['content_type'] = $attr['content_type'] ?? $amqpEnvelope->getContentType();
$attr['content_encoding'] = $attr['content_encoding'] ?? $amqpEnvelope->getContentEncoding();
$attr['delivery_mode'] = $attr['delivery_mode'] ?? $amqpEnvelope->getDeliveryMode();
$attr['priority'] = $attr['priority'] ?? $amqpEnvelope->getPriority();
$attr['timestamp'] = $attr['timestamp'] ?? $amqpEnvelope->getTimestamp();
$attr['app_id'] = $attr['app_id'] ?? $amqpEnvelope->getAppId();
$attr['message_id'] = $attr['message_id'] ?? $amqpEnvelope->getMessageId();
$attr['user_id'] = $attr['user_id'] ?? $amqpEnvelope->getUserId();
$attr['expiration'] = $attr['expiration'] ?? $amqpEnvelope->getExpiration();
$attr['type'] = $attr['type'] ?? $amqpEnvelope->getType();
$attr['reply_to'] = $attr['reply_to'] ?? $amqpEnvelope->getReplyTo();

return new self($previousStamp->routingKey ?? $amqpEnvelope->getRoutingKey(), $previousStamp->flags ?? AMQP_NOPARAM, $attr);
}

public static function createWithAttributes(array $attributes, self $previousStamp = null): self
{
return new self(
$previousStamp->routingKey ?? null,
$previousStamp->flags ?? AMQP_NOPARAM,
array_merge($previousStamp->attributes ?? [], $attributes)
);
}
}
Original file line number Diff line number Diff line change
Expand Up @@ -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);
Copy link
Member

Choose a reason for hiding this comment

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

This looks subjective either way (or am I missing something)? The $headers comes ultimately from the serializer. So, should headers from the AmqpStamp win or headers from the serialization of the message. I dunno :). But I was curious what motivated the change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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).

Copy link
Contributor

Choose a reason for hiding this comment

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

This was huge BC break, it broke our app and make overriding type header impossible.


$exchange->publish(
$body,
Expand Down