8000 [Messenger] Respect `isRetryable` decision of the retry strategy for re-delivery by FlyingDR · Pull Request #49063 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[Messenger] Respect isRetryable decision of the retry strategy for re-delivery #49063

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
May 12, 2023
Merged

[Messenger] Respect isRetryable decision of the retry strategy for re-delivery #49063

merged 1 commit into from
May 12, 2023

Conversation

FlyingDR
Copy link
Contributor
Q A
Branch? 5.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets
License MIT
Doc PR

Documentation for retry strategy for the Messenger component declares that message will not be retried to be re-delivered more than the value of max_retries configuration for the retry strategy.

However, after merging #36557 actual implementation gives priority to the existence of the RecoverableExceptionInterface, effectively opening a way for a message to be re-delivered indefinitely.

Additionally, in the case of using multiplier with a value of more than 1 this unlimited re-delivery causes unlimited growth of the delay value for the DelayStamp. Its type is defined as int, so on 32-bit platforms after some time delay value may exceed PHP_INT_MAX which will lead to the TypeError.

The proposed change enforces respect for the max_retries setting value for the decision of re-delivery.

@FlyingDR
[Messenger] Respect isRetryable decision of the retry strategy when…
8fc3dcc 
… deciding if failed message should be re-delivered
@carsonbot carsonbot added this to the 5.4 milestone Jan 22, 2023
@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.3 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

@carsonbot
Copy link

Hey!

I think @deguif has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

@FlyingDR
Copy link
Contributor Author
FlyingDR commented May 3, 2023

@nicolas-grekas Any chance for review? :)

@fabpot
Copy link
Member
fabpot commented May 12, 2023

Thank you @FlyingDR.

@fabpot fabpot merged commit f055c80 into symfony:5.4 May 12, 2023
@FlyingDR FlyingDR deleted the respect-retryable-from-retry-strategy branch May 12, 2023 09:01
This was referenced May 22, 2023
Merged
Merged
Merged
@rodnaph
Copy link
Contributor
rodnaph commented Jun 1, 2023

@FlyingDR The current docs suggest RecoverableMessageHandlingException (via RecoverableExceptionInterface) will be retried indefinitely, but from my reading this PR changes that behaviour so that it will only retry as per retry-strategy. Is that correct?

image

We were previously using this to retry messages which may possibly fail more times than the retry strategy.

Do the docs need updating, or has this introduced a regression? It seems this makes the above interface meaningless as all messages will be retried as per retry-strategy anyway.

@FlyingDR
Copy link
Contributor Author
FlyingDR commented Jun 1, 2023

@FlyingDR The current docs suggest RecoverableMessageHandlingException (via RecoverableExceptionInterface) will be retried indefinitely, but from my reading this PR changes that behaviour so that it will only retry as per retry-strategy. Is that correct?

It is a good point, @rodnaph, thank you. It really looks like a contradiction.

From my point of view ignoring the limit which is explicitly defined in the configuration is not a good idea by itself, at least not in case if it is done silently. Also, as I wrote in the description of the pull request - there is a possibly unwanted side effect when using redelivery along with multiplier configuration.

We were previously using this to retry messages which may possibly fail more times than the retry strategy.

You can still do it by creating your own service that implements RetryStrategyInterface and tell Symfony to use it by using the retry_strategy.service configuration option. It may be hard to notice its existence from the documentation, but it is available.

Do the docs need updating, or has this introduced a regression? It seems this makes the above interface meaningless as all messages will be retried as per retry-strategy anyway.

Documentation has to be updated, you're right, thank you. I will provide a PR for it.

@rodnaph
Copy link
Contributor
rodnaph commented Jun 2, 2023

@FlyingDR Thanks for the clarification and suggested workaround 👍

Also, as I wrote in the description of the pull request - there is a possibly unwanted side effect when using redelivery along with multiplier configuration.

This sounds like a separate issue that should be addressed in that retry strategy.

@nicolas-grekas As it stands I think this PR should be reverted as it causes a regression in existing functionality. If it's decided that this functionality is undesirable and should be removed then that can be done by deprecating and then removing in a future release. WDYT?

@bendavies bendavies mentioned this pull request Jun 14, 2023
Merged
@fabpot
Copy link
Member
fabpot commented Jun 21, 2023

This PR has now been reverted.

fabpot added a commit that referenced this pull request Jun 21, 2023
@fabpot
bug #50655 Revert "Respect isRetryable decision of the retry strategy…
4beb102 
… for re-delivery" (bendavies)

This PR was merged into the 5.4 branch.

Discussion
----------

Revert "Respect isRetryable decision of the retry strategy for re-delivery"

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Reverts #49063
| License       | MIT
| Doc PR        |

Revert "[Messenger] Respect `isRetryable` decision of the retry strategy when deciding if failed message should be re-delivered"

This reverts #49063

The linked PR rendered `RecoverableExceptionInterface` useless - i.e. it would not retry indefinately as stated in the docs.

See the [discussion on the original PR](#49063 (comment))

Commits
-------

dd328a2 Revert "[Messenger] Respect `isRetryable` decision of the retry strategy when deciding if failed message should be re-delivered"
@renovate renovate bot mentioned this pull request Dec 5, 2023
Open
1 task
This was referenced Feb 26, 2025
Closed
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@fabpot fabpot fabpot approved these changes

@nicolas-grekas nicolas-grekas nicolas-grekas approved these changes

Assignees
No one assigned
Labels
Bug Messenger Status: Reviewed
Projects
None yet
Milestone
5.4
Development

Successfully merging this pull request may close these issues.
6 participants
@FlyingDR @carsonbot @fabpot @rodnaph @nicolas-grekas @fwolfsjaeger
0