Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Messenger] Refactoring failure to FailedMessage & allowing for requeue#31397

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

@weaverryan
Copy link
Member

@weaverryanweaverryan commentedMay 6, 2019
edited
Loading

QA
Branch?master
Bug fix?partially
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed ticketsnone
LicenseMIT
Doc PRsymfony/symfony-docs#11236

There are a few things going on:

  1. Purely because I think it's a better implementation, I've created a newFailedMessage class and the failed messages go inside of this. This message is then routed to the failure transport.

  2. This adds the ability to "requeue" messages instead of retrying them immediately, based on feedback from Twitter.

  3. This should fix an undiscovered bug: if you "retry" and use[Messenger] Allows to register handlers on a specific transport #30958, previously, retrying would not execute the correct handlers because it would appear the message was being received from the "failure" transport, not the original transport, which has configuration to execute specific handlers.

Cheers!

@weaverryanweaverryanforce-pushed thefailure-transport-message-requeue branch from9bd0543 to86975f5CompareMay 6, 2019 16:28
@weaverryanweaverryan added this to the4.3 milestoneMay 6, 2019
@weaverryanweaverryanforce-pushed thefailure-transport-message-requeue branch from86975f5 to4c83e1cCompareMay 6, 2019 17:21
@weaverryanweaverryan requested a review fromsroze as acode ownerMay 6, 2019 17:21
@weaverryanweaverryanforce-pushed thefailure-transport-message-requeue branch from4c83e1c to6b19228CompareMay 6, 2019 17:22
Copy link
MemberAuthor

@weaverryanweaverryan left a comment

Choose a reason for hiding this comment

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

Much of this PR is just a revert of part of#30970. I've highlighted those to help review.

->replaceArgument(0,$messageToSendersMapping)
->replaceArgument(1, ServiceLocatorTagPass::register($container,$senderReferences))
->replaceArgument(2,$messagesToSendAndHandle)
->replaceArgument(1,$messagesToSendAndHandle)
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

All of the logic from$senders = [] is a revert of#30970

if (!isset($senderAliases[$failureTransport])) {
$senderAliases[$failureTransport] =$failureTransport;
}
}
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

This section was mostly just moved from below. The$messagesToSendersMapping is the new part: it addsrouting for theFailedMessage class to whatever the failure transport is.


<tagname="console.command"command="messenger:failed:remove" />
</service>

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Moved into a new file so we can conditionally import that file (instead importing, then removing if the failure transport is disabled).

<argumenttype="collection" /><!-- Per message senders map-->
<argument /><!-- senders locator-->
<argumenttype="collection" /><!-- Per message sender iterators-->
<argumenttype="collection" /><!-- Messages to send and handle-->
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Revert of#30970

$this->assertEquals(newReference('audit'),$sendersLocator->getArgument(0)['audit']->getValues()[0]);
'amqp' =>newReference('messenger.transport.amqp'),
'audit' =>newReference('audit'),
],$sendersMapping[DummyMessage::class]->getValues());
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Revert of#30970

}

returnfalse;
}
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Revert of#30970

});

returnnewSendersLocator($sendersMap,$container,$sendAndHandle);
}
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Whole class is a revert of#30970


publicfunctiontestGetters()
{
$stamp =newRedeliveryStamp(10,'sender_alias');
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Revert of#30970

});

return$container;
$this->assertSame(['dummy' =>$sender],iterator_to_array($locator->getSenders(newEnvelope(newDummyMessage('a')))));
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Revert of#30970

}

thrownewUnknownSenderException(sprintf('Unknown sender alias "%s".',$alias));
}
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Revert of#30970

@weaverryanweaverryanforce-pushed thefailure-transport-message-requeue branch 4 times, most recently from8e62086 tod4f483fCompareMay 6, 2019 18:54
useSymfony\Component\Messenger\Transport\Sender\SendersLocator;
useSymfony\Component\Messenger\Worker;

class FailureIntegrationTestextends TestCase
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

This test is a bit crazy. There are various layers that interact, and this proves the work together:

  1. The ability to send a message to multiple transports but some handlers are only called on some transports
  2. The failure transport and the requeuing of messages
  3. The failure transport and retrying messages (instead of requeuing) and making sure the correct handlers are still called.

@weaverryanweaverryanforce-pushed thefailure-transport-message-requeue branch 2 times, most recently from6020703 to1b0b49dCompareMay 7, 2019 15:26
@Tobion
Copy link
Contributor

Tobion commentedMay 7, 2019
edited
Loading

I like the new implementation. But now that FailedMessage are routed using the standard config, does it not mean that the FailedMessage will also be routed to transports configured by the user using the wildcard, e.g.* => amqp. So the FailedMessage would go to the failure transport as well as amqp. Which will probably fail again and then send the message to both transports, creating an endless loop.

@weaverryanweaverryanforce-pushed thefailure-transport-message-requeue branch from1b0b49d toc776abdCompareMay 7, 2019 19:11
@weaverryanweaverryanforce-pushed thefailure-transport-message-requeue branch fromc776abd to3ab3a85CompareMay 7, 2019 19:12
Copy link
Contributor

@srozesroze left a comment

Choose a reason for hiding this comment

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

As discussed on Slack, I think this approach as multiple downsides:

  1. It doesn't work with* as@Tobion spotted well
  2. It forces the failure transport to only use the PHPserialize serializer (because Symfony Serializer couldn't know how to deserialize theFailedMessage message; especially its innerEnvelope)
  3. It forces the entirety of the "system" to only have one "failure transport"

Also, all of this change is trigged by the point 2) of the pull-request description, which, IMHO, could be simply achieved by dispatching the message again (without theReceivedStamp). I agree that we need to look at 3) which might be a bug though.

$messageToSendersMapping = [];
$messagesToSendAndHandle = [];
if ($config['failure_transport']) {
$failureTransport =$config['failure_transport'];
Copy link
Contributor

Choose a reason for hiding this comment

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

This line could be in theif :)

@weaverryan
Copy link
MemberAuthor

After talking with Sam & Nicolas (and@Tobion's feedback), I'm closing this PR. Most of this code was a refactoring, which didn't contain enough objective improvements over the previous implementation.

We can propose requeue for 4.4, as it's a new feature.

And for:

  1. This should fix an undiscovered bug: if you "retry" and use[Messenger] Allows to register handlers on a specific transport #30958, previously, retrying would not execute the correct handlers because it would appear the message was being received from the "failure" transport, not the original transport, which has configuration to execute specific handlers.

I'll attempt to fix this independently in another PR.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

2 more reviewers

@TobionTobionTobion left review comments

@srozesrozesroze requested changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.3

Development

Successfully merging this pull request may close these issues.

4 participants

@weaverryan@Tobion@sroze@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp