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

Skip to content

[Messenger] no possibility to prevent retrying at this moment | UnrecoverableMessageHandlingException not working #32325

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

Closed
wtorsi opened this issue Jul 2, 2019 · 2 comments

Comments

@wtorsi
Copy link

wtorsi commented Jul 2, 2019

v4.3.2

When using async transport, UnrecoverableMessageHandlingException business logic does not work at this moment at all.
Symfony\Component\Messenger\Middleware\HandleMessageMiddleware:82 wraps all \Throwable (not only UnrecoverableExceptionInterface exceptions) occurred in handlers in Symfony\Component\Messenger\Exception\HandlerFailedException, when Symfony\Component\Messenger\Worker:194 wants only UnrecoverableExceptionInterface.
At this moment the only possible solution to prevent retrying is disable totally retrying strategy.

To reproduce, just throw UnrecoverableExceptionInterface in any kind of async handlers (i did not test on sync handlers, but think that situation is the same).

As a solution, it's be better to check payload of HandlerFailedException in Worker.

@Tobion
Copy link
Contributor

Tobion commented Jul 2, 2019

Confirmed, see

if ($throwable instanceof HandlerFailedException) {
$envelope = $throwable->getEnvelope();
}
$shouldRetry = $retryStrategy && $this->shouldRetry($throwable, $envelope, $retryStrategy);

Suggestion as bug-fix:

  • When there is only one nested exception, use that to check for UnrecoverableExceptionInterface (most common situation with a single handler)
  • When there are more than one nested exception, always retry (like now) because we can't really decide

Suggestion as new feature:

  • Pass the exception to the RetryStrategyInterface. This way custom retry strategies can change the logic based on the exception and for example make a better decision when there are more than one nested exceptions in several handlers.

@weaverryan
Copy link
Member

Suggestion as bug-fix:

  • When there is only one nested exception, use that to check for UnrecoverableExceptionInterface (most common situation with a single handler)

+1

  • When there is more than one nested exception, always retry (like now) because we can't really decide

Yes, certainly for 4.3. But also, we could (in HandleMessageMiddlware) attach the HandledStamp for that handler to effectively make it "look handled". A retry would only retry the other handlers. This could get a bit tricky, so I think it's ok to make a first bug fix PR without this, then tackle this later.

Suggestion as new feature:

  • Pass the exception to the RetryStrategyInterface. This way custom retry strategies can change the logic based on the exception and for example make a better decision when there are more than one nested exceptions in several handlers.

That is certainly very sensible.

@fabpot fabpot closed this as completed Jul 19, 2019
fabpot added a commit that referenced this issue Jul 19, 2019
…LanaiGrunt)

This PR was merged into the 4.3 branch.

Discussion
----------

[Messenger] Fix UnrecoverableExceptionInterface handling

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

Fixed the handling of UnrecoverableExceptionInterface-Exceptions like suggested in [the issue thread](#32325 (comment)).

Commits
-------

49bb743 [Messenger] fixed UnrecoverableExceptionInterface handling in Worker (fixes #32325)
symfony-splitter pushed a commit to symfony/messenger that referenced this issue Jul 19, 2019
…LanaiGrunt)

This PR was merged into the 4.3 branch.

Discussion
----------

[Messenger] Fix UnrecoverableExceptionInterface handling

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

Fixed the handling of UnrecoverableExceptionInterface-Exceptions like suggested in [the issue thread](symfony/symfony#32325 (comment)).

Commits
-------

49bb7435f1 [Messenger] fixed UnrecoverableExceptionInterface handling in Worker (fixes #32325)
nicolas-grekas added a commit that referenced this issue Jul 19, 2019
* 4.3:
  fix tests
  [Validator] Added support for validation of giga values
  Fix Debug component tests
  [Messenger] fixed UnrecoverableExceptionInterface handling in Worker (fixes #32325)
  [Messenger] pass transport name to factory
nicolas-grekas added a commit that referenced this issue Jul 19, 2019
* 4.4:
  fix tests
  [Validator] Added support for validation of giga values
  Fix Debug component tests
  [Messenger] fixed UnrecoverableExceptionInterface handling in Worker (fixes #32325)
  [Messenger] pass transport name to factory
symfony-splitter pushed a commit to symfony/messenger that referenced this issue Jan 28, 2020
…LanaiGrunt)

This PR was merged into the 4.3 branch.

Discussion
----------

[Messenger] Fix UnrecoverableExceptionInterface handling

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

Fixed the handling of UnrecoverableExceptionInterface-Exceptions like suggested in [the issue thread](symfony/symfony#32325 (comment)).

Commits
-------

49bb7435f1 [Messenger] fixed UnrecoverableExceptionInterface handling in Worker (fixes #32325)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants