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

[FlyingDR]

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.

[carsonbot]

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]

Hey!

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

Cheers!

Carsonbot

[FlyingDR]

@nicolas-grekas Any chance for review? :)

[fabpot]

Thank you @FlyingDR.

[rodnaph]

@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?

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]

@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]

@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?

[fabpot]

This PR has now been reverted.