Retry Policies
Steps can define retry behavior for transient failures. If a step fails and has a retry policy, the engine will automatically re-attempt execution.
Per-Step Configuration
Add a retry key to any step definition:
php
'process_payment' => [
'type' => 'action',
'handler' => 'charge_card',
'retry' => [
'max_attempts' => 3,
'backoff' => 'exponential', // 'fixed', 'linear', or 'exponential'
'delay_seconds' => 5, // Base delay between retries
],
]Backoff Strategies
| Strategy | Delay Pattern | Example (5s base) |
|---|---|---|
fixed | Same delay every retry | 5s, 5s, 5s |
linear | Delay grows linearly | 5s, 10s, 15s |
exponential | Delay doubles each retry | 5s, 10s, 20s |
Global Default
Set a default retry policy for all steps in config/workflowable.php:
php
'execution' => [
'default_retry' => [
'max_attempts' => 3,
'backoff' => 'exponential',
'delay_seconds' => 5,
],
],Per-step retry configuration overrides the global default. Set 'retry' => null on a step to explicitly disable retries even when a global default is set.
Events
| Event | When |
|---|---|
StepRetrying | Before each retry attempt. Properties: $execution, $attempt, $delaySeconds |
StepFailed | After final failure. Properties: $execution, $exception, $willRetry |
The $willRetry property on StepFailed indicates whether the step will be retried. It's false when all attempts are exhausted.
Example: Payment Processing
php
'steps' => [
'charge_card' => [
'type' => 'action',
'handler' => 'charge_card',
'retry' => [
'max_attempts' => 3,
'backoff' => 'exponential',
'delay_seconds' => 2,
],
],
'send_receipt' => [
'type' => 'action',
'handler' => 'send_receipt',
'retry' => [
'max_attempts' => 5,
'backoff' => 'fixed',
'delay_seconds' => 10,
],
],
],Payment processing uses exponential backoff (2s, 4s, 8s) for gateway timeouts, while email sending uses fixed delays (10s each) for SMTP issues.