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

Skip to content

[Messenger] On failure retry, make message appear received from original sender #31425

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
May 11, 2019

Conversation

weaverryan
Copy link
Member

@weaverryan weaverryan commented May 8, 2019

Q A
Branch? master (4.3)
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #31413
License MIT
Doc PR symfony/symfony-docs#11236

Fixes a bug when using the transport-based handler config from #30958. This also adds a pretty robust integration test that dispatches a complex message with transport-based handler config, failures, failure transport, etc - and verifies the correct behavior.

Cheers!

@weaverryan weaverryan added this to the 4.3 milestone May 8, 2019
@weaverryan weaverryan force-pushed the messenger-retry-from-same-transport branch from 4e6848a to db47a21 Compare May 8, 2019 14:42
@weaverryan weaverryan force-pushed the messenger-retry-from-same-transport branch 3 times, most recently from 8ad8b4c to ce9154f Compare May 8, 2019 18:08
@@ -154,7 +154,7 @@ private function runInteractive(SymfonyStyle $io, bool $shouldForce)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why it is only collecting one message at a time a few lines above foreach ($receiver->all(1) as $envelope) {? Wouldn't it be better to batch more messages to avoid querying doctrine for each message?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm. We could... but I don't see a lot of benefit. This is the interactive mode, and we're asking the user if they want to retry one-by-one. In theory, something else could also be reading from the failure transport at the same time, so getting whatever the latest id is one-by-one seems sensible.

@@ -51,11 +50,8 @@ public function onMessageFailed(WorkerMessageFailedEvent $event)
$envelope = $event->getEnvelope();

// avoid re-sending to the failed sender
Copy link
Contributor

Choose a reason for hiding this comment

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

I see that it makes sense. Otherwise consuming the failure transport could be an endless loop of processing and failing and requeuing.
But I think it should be explicitly warned in the retry command that the message will be gone after retrying it even if it fails again.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, exactly. However, the failure transport acts like any normal transport. If the transport has retries configured (by default it does, and the default is 3 tries), the message will be retried 3 times on the failure transport before being discarded. In this PR, I even added some extra info on the retry command that says that this message has already been tried 1/2/3... times on the failure transport previously.

@weaverryan weaverryan force-pushed the messenger-retry-from-same-transport branch from ce9154f to ecff07b Compare May 9, 2019 01:09
@weaverryan
Copy link
Member Author

This should be ready - tests passing - ready for review!

@nicolas-grekas nicolas-grekas changed the base branch from master to 4.3 May 9, 2019 14:00
@weaverryan weaverryan force-pushed the messenger-retry-from-same-transport branch 4 times, most recently from 0927cf0 to 62f0bb6 Compare May 10, 2019 15:19
@weaverryan
Copy link
Member Author

Ready to go again. This is mostly a small fix + some refactoring based on @Tobion's recommendations. The vast majority of the added lines are in a robust new integration test.

@fabpot fabpot force-pushed the messenger-retry-from-same-transport branch from 62f0bb6 to 80b5df2 Compare May 11, 2019 06:54
@fabpot
Copy link
Member

fabpot commented May 11, 2019

Thank you @weaverryan.

@fabpot fabpot merged commit 80b5df2 into symfony:4.3 May 11, 2019
fabpot added a commit that referenced this pull request May 11, 2019
… from original sender (weaverryan)

This PR was squashed before being merged into the 4.3 branch (closes #31425).

Discussion
----------

[Messenger] On failure retry, make message appear received from original sender

| Q             | A
| ------------- | ---
| Branch?       | master (4.3)
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #31413
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

Fixes a bug when using the transport-based handler config from #30958. This also adds a pretty robust integration test that dispatches a complex message with transport-based handler config, failures, failure transport, etc - and verifies the correct behavior.

Cheers!

Commits
-------

80b5df2 [Messenger] On failure retry, make message appear received from original sender
@weaverryan weaverryan deleted the messenger-retry-from-same-transport branch May 14, 2019 10:50
@fabpot fabpot mentioned this pull request May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants