[FrameworkBundle][Messenger] Add RetryStrategyStamp
#62278
Conversation
RetryStrategyStampRetryStrategyStamp
1fa3c11 to
adec243
Compare
| */ | ||
| final class DynamicRetryStrategy implements RetryStrategyInterface | ||
| { | ||
| public function __construct(private RetryStrategyInterface $fallbackStrategy) |
There was a problem hiding this comment.
| public function __construct(private RetryStrategyInterface $fallbackStrategy) | |
| public function __construct(private readonly RetryStrategyInterface $fallbackStrategy) |
| public function __construct( | ||
| private ?bool $retryable = null, | ||
| private ?int $waitingTime = null, | ||
| ) { | ||
| } | ||
|
|
||
| public function isRetryable(): ?bool | ||
| { | ||
| return $this->retryable; | ||
| } | ||
|
|
||
| public function getWaitingTime(): ?int | ||
| { | ||
| return $this->waitingTime; | ||
| } |
There was a problem hiding this comment.
| public function __construct( | |
| private ?bool $retryable = null, | |
| private ?int $waitingTime = null, | |
| ) { | |
| } | |
| public function isRetryable(): ?bool | |
| { | |
| return $this->retryable; | |
| } | |
| public function getWaitingTime(): ?int | |
| { | |
| return $this->waitingTime; | |
| } | |
| public function __construct( | |
| public readonly ?bool $retryable = null, | |
| public readonly ?int $waitingTime = null, | |
| ) { | |
| } |
nicolas-grekas
left a comment
There was a problem hiding this comment.
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.
It also configures the delay, not only retryability.
Overall this is PR is more just an idea & a tiny step to get closer to implementing message chains (#50462) and not something I'm after as-is, though it may solve some other use-cases also (like #62056). |
Sometimes you only know if a message should be retried or not when dispatching the message, e.g.
RunCommandMessagewith one command should be retried, but not with another command. I'm proposing to add a stamp & decorator strategy to make that possible.Examples
or e.g. if a single message class should never be retried:
It is worth noting that
RecoverableMessageInterface&UnrecoverableExceptionInterfacewould still have higher priority than this stamp.This is somewhat related to #62056 & could be useful for #50462 to allow chain-specific retry behavior.