Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[FrameworkBundle][Messenger] AddRetryStrategyStamp#62278

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
valtzu wants to merge1 commit intosymfony:7.4
base:7.4
Choose a base branch
Loading
fromvaltzu:dynamic-retry-strategy

Conversation

@valtzu
Copy link
Contributor

QA
Branch?7.4
Bug fix?no
New feature?yes
Deprecations?no
LicenseMIT

Sometimes you only know if a message should be retried or not when dispatching the message, e.g.RunCommandMessage with one command should be retried, but not with another command. I'm proposing to add a stamp & decorator strategy to make that possible.

Examples

$this->bus->dispatch(newRunCommandMessage('do:not:retry'), [newRetryStrategyStamp(retryable:false)]);$this->bus->dispatch(newRunCommandMessage('always:retry'), [newRetryStrategyStamp(retryable:true)]);$this->bus->dispatch(newRunCommandMessage('always:retry:custom-delay'), [newRetryStrategyStamp(retryable:true, waitingTime:10_000)]);$this->bus->dispatch(newRunCommandMessage('retry:custom-delay'), [newRetryStrategyStamp(waitingTime:10_000)]);

or e.g. if a single message class should never be retried:

#[AsMessage]class NeverRetryThisMessageimplements DefaultStampsProviderInterface{// ...publicfunctiongetDefaultStamps():array    {return [newRetryStrategyStamp(retryable:false)];    }}

It is worth noting thatRecoverableMessageInterface &UnrecoverableExceptionInterface would still have higher priority than this stamp.


This is somewhat related to#62056 & could be useful for#50462 to allow chain-specific retry behavior.

santysisi reacted with thumbs up emojisantysisi reacted with heart emojisantysisi reacted with rocket emoji
@carsonbotcarsonbot added this to the7.4 milestoneNov 2, 2025
@carsonbotcarsonbot changed the title[Messenger][FrameworkBundle] AddRetryStrategyStamp[FrameworkBundle][Messenger] AddRetryStrategyStampNov 2, 2025
@valtzuvaltzuforce-pushed thedynamic-retry-strategy branch from1fa3c11 toadec243CompareNovember 2, 2025 15:58
*/
final class DynamicRetryStrategy implements RetryStrategyInterface
{
public function __construct(private RetryStrategyInterface $fallbackStrategy)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
publicfunction __construct(privateRetryStrategyInterface$fallbackStrategy)
publicfunction __construct(privatereadonlyRetryStrategyInterface$fallbackStrategy)

Comment on lines +21 to +35
publicfunction__construct(
private ?bool$retryable =null,
private ?int$waitingTime =null,
) {
}

publicfunctionisRetryable(): ?bool
{
return$this->retryable;
}

publicfunctiongetWaitingTime(): ?int
{
return$this->waitingTime;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
publicfunction __construct(
private ?bool$retryable =null,
private ?int$waitingTime =null,
) {
}
publicfunction isRetryable(): ?bool
{
return$this->retryable;
}
publicfunction getWaitingTime(): ?int
{
return$this->waitingTime;
}
publicfunction __construct(
publicreadonly ?bool$retryable =null,
publicreadonly ?int$waitingTime =null,
) {
}

Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

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

Not sure about the name: this doesn't configure the strategy - just the retriability
Also, when retryable = true I'm not sure this makes sense
NoRetryStamp might be more appropriate for disabling retries.

But then: you example about RunCommandMessage makes me think this is a concern that belongs to the message - not to the stamp. The question is: from the pov of messenger, should a failure of the command mean that the message wasn't handled successfully? It depends if the failure comes from the command being unable to run because eg it failed to start (missing binary, etc) or because the message yields to an non-zero exit code. Which is the case you want to skip.

Alternative idea: make this a concern of RunCommandMessage (and RunProcessMessage) - eg with status codes to consider OK from the pov of messenger.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas left review comments

+1 more reviewer

@santysisisantysisisantysisi left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

7.4

Development

Successfully merging this pull request may close these issues.

4 participants

@valtzu@nicolas-grekas@santysisi@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp