Skip to content
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

[Messenger] Ensure message is handled only once per handler #30020

Merged
merged 2 commits into from Apr 6, 2019

Conversation

keulinho
Copy link
Contributor

@keulinho keulinho commented Jan 29, 2019

Add check to ensure that a message is only handled once per handler
Add try...catch to run all handlers before throwing exception

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #27215
License MIT
Doc PR Todo

This would make error handling and retrying of messages much more easier. As statet here #27008 (comment) there is currently no way to retry a for all failed handlers if there are mutliple handlers and just some throw an exception.
Also if an Exception in an handler occurs the execution chain is disrupted and the other handlers are never invoked.
With this change it is easily possible to create an userland middleware that catches the ChainedHandlerFailedException and does some custom retry logic. If you ensure that the HandledStamps on the Envelope are preserved the message will be handled just by the failed handlers

@sroze
Copy link
Contributor

sroze commented Mar 23, 2019

We need to wait for #30557 to be merged to go forward with this one because we need to make sure the HandledStamps are kept when retrying then.

But either way, wouldn't it make more sense to retry all the listeners by default? It might cause even more inconsistency if we only call the "remaining listeners" isn't it? (only if they are related to each other I guess)

@fabpot
Copy link
Member

fabpot commented Mar 23, 2019

#30557 is merged now :)

@weaverryan
Copy link
Member

@keulinho can you rebase now that #30557 is merged? This is a missing piece to handling failures correctly. It could be a bit more complex, but I'm wondering if we should add an integration test involving Worker with a fake "receiver" and a bus with all the default middleware. That would allow us to test this complex behavior: e.g. use Worker to "receive" a message that has 2 handlers where 1 fails the first time. Then see that there was a retry, but each handler was ultimately only called 1 time. The whole "flow" really involves Worker and several middleware working together properly.

But either way, wouldn't it make more sense to retry all the listeners by default? It might cause even more inconsistency if we only call the "remaining listeners" isn't it? (only if they are related to each other I guess)

Hmm, I don't think I agree with this. It seems like more risk to knowingly execute a handler two times.

@keulinho keulinho force-pushed the handle-messages-once-per-handler branch from 1826b88 to f18bd98 Compare March 26, 2019 09:19
@keulinho keulinho requested a review from sroze as a code owner March 26, 2019 09:19
@keulinho keulinho force-pushed the handle-messages-once-per-handler branch 2 times, most recently from 92065aa to dca8b9e Compare March 26, 2019 09:22
@keulinho keulinho force-pushed the handle-messages-once-per-handler branch 3 times, most recently from 117ec51 to 7c6fb32 Compare March 29, 2019 08:25
@weaverryan
Copy link
Member

@keulinho could you please rebase again? And mark the previous comments as "Resolved" if you've handled them. A lot of things are being merged to messenger currently - so sorry for the repeated rebasing!

@keulinho keulinho force-pushed the handle-messages-once-per-handler branch 3 times, most recently from 713158c to 1cdf048 Compare April 2, 2019 13:59
@sroze
Copy link
Contributor

sroze commented Apr 6, 2019

I've changed the exception name to HandlerFailedException and added a note in the CHANGELOG.

$handledStamp = HandledStamp::fromCallable($handler, $handler($message), \is_string($alias) ? $alias : null);
$envelope = $envelope->with($handledStamp);
$this->logger->info('Message "{class}" handled by "{handler}"', $context + ['handler' => $handledStamp->getCallableName()]);
$alias = \is_string($alias) ? $alias : null;
Copy link
Member

Choose a reason for hiding this comment

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

What if $alias is null and there are 2 handlers? Wouldn't that cause the second one to "appear" like it was handled? I think if the $alias is null, we have to assume that the message has not already been handled always.

Copy link
Contributor

Choose a reason for hiding this comment

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

They would not appear as handled because we track the handler name. Alias is just an optional thing we actually don't use in core. (I think we could even remove it, it's been introduced - #29166 - on the assumption that it might be useful later, while it complexifies reading this code).

@@ -66,6 +78,21 @@ public function handle(Envelope $envelope, StackInterface $stack): Envelope
$this->logger->info('No handler for message "{class}"', $context);
}

if (\count($exceptions)) {
throw new HandlerFailedException($envelope, ...$exceptions);
}
Copy link
Member

Choose a reason for hiding this comment

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

Just thinking out loud: one practical implication is that, if someone listens on the new WorkerMessageFailedEvent event, they will always (well, not technically "always", but pretty much always) receive this exception instead of the actual exception. Then they'll need to loop over getNestedExceptions() if they want to look for a specific exception. I think that's ok, just stating that.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, exactly. I was thinking whether it would make sense or not to throw the original exception if there is only one but it would mean you need to catch your own exception plus HandlerFailedException. So better always throwing it.

@sroze sroze force-pushed the handle-messages-once-per-handler branch 3 times, most recently from 4fc0e80 to 2bd4d29 Compare April 6, 2019 12:33
@sroze sroze dismissed weaverryan’s stale review April 6, 2019 12:40

Discussed on Slack 👍

keulinho and others added 2 commits April 6, 2019 14:40
Add check to ensure that a message is only handled once per handler
Add try...catch to run all handlers before throwing exception
@sroze sroze force-pushed the handle-messages-once-per-handler branch from 2bd4d29 to 2e5e910 Compare April 6, 2019 12:41
@fabpot
Copy link
Member

fabpot commented Apr 6, 2019

Thank you @keulinho.

@fabpot fabpot merged commit 2e5e910 into symfony:master Apr 6, 2019
fabpot added a commit that referenced this pull request Apr 6, 2019
…ndler (keulinho, sroze)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[Messenger] Ensure message is handled only once per handler

Add check to ensure that a message is only handled once per handler
Add try...catch to run all handlers before throwing exception

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? |no
| Tests pass?   | yes
| Fixed tickets | #27215
| License       | MIT
| Doc PR        | Todo

This would make error handling and retrying of messages much more easier. As statet  here #27008 (comment) there is currently no way to retry a for all failed handlers if there are mutliple handlers and just some throw an exception.
Also if an Exception in an handler occurs the execution chain is disrupted and the other handlers are never invoked.
With this change it is easily possible to create an userland middleware that catches the `ChainedHandlerFailedException` and does some custom retry logic. If you ensure that the `HandledStamps` on the `Envelope` are preserved the message will be handled just by the failed handlers

Commits
-------

2e5e910 Rename exception, add change log and a few other things
e6e4cde Ensure message is handled only once per handler
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.3 Apr 30, 2019
@fabpot fabpot mentioned this pull request May 9, 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.

None yet

7 participants