Hey!

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

Symfony has acontribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (seehttps://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (seehttps://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

Hey!

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

Cheers!

Carsonbot

@nicolas-grekas Any chance for review? :)

Thank you@FlyingDR.

@FlyingDR The current docs suggestRecoverableMessageHandlingException (viaRecoverableExceptionInterface) 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 The current docs suggestRecoverableMessageHandlingException (viaRecoverableExceptionInterface) 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 withmultiplier 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 implementsRetryStrategyInterface and tell Symfony to use it by using theretry_strategy.service configuration option. It may be hard to notice its existence from the documentation, but it isavailable.

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.

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

This PR has now been reverted.