Skip to main content
Version: Next

Retry Processor

Overview​

The Retry processor automatically retries failed requests based on configurable parameters. It helps improve reliability by ensuring transient failures do not cause immediate request failures. Users can define the number of retry attempts and cooldown settings to optimize API performance.

Retry

Input and Output​

This processor works on the response stream:

  • Input Stream: Response – The processor intercepts the response from the provider, checking whether the request should be retried based on the defined parameters (e.g., the number of retry attempts and cooldown periods).

  • Output Streams: Response –

    • Failed – If the retry attempts are exhausted or the response is still unsuccessful, it will be routed to the failed stream.

    • Retry – If the response meets the retry criteria, it will be re-sent to the provider and routed through the retry stream.

This ensures that the request is retried automatically if it fails, offering a better user experience by handling intermittent failures more gracefully.

Parameters​

Each parameter is defined as a key-value pair inside the parameters section.

attempts​

Type: number
Required: True
Defines the number of attempts to retry a failed request before giving up.

Example:

- key: attempts
  value: 3

cooldown_between_attempts_seconds​

Type: number
Required: False
Default: 0
Specifies the time in seconds to wait between each retry attempt.

Example:

- key: cooldown_between_attempts_seconds
  value: 5

cooldown_multiplier​

Type: number
Required: False
Default: 0
Determines the multiplier applied to the cooldown time between retries, allowing for exponential backoff strategies.

Example:

- key: cooldown_multiplier
  value: 2

maximum_cooldown_seconds​

Type: number
Required: False
Default: 0
The maximum time in seconds to wait between each retry (even if the multiplier is applied and the cooldown is greater than this value).

Best Practices​

  • Set attempts to a reasonable number to avoid excessive retries that may overload the system.
  • Use cooldown_between_attempts_seconds to prevent immediate retry loops.
  • Apply cooldown_multiplier for exponential backoff to handle traffic spikes efficiently.

For more details on configuring flows, visit the Lunar.dev Flows Documentation.

Retry Processor Template​

Retry Processor
Retry:
  processor: Retry
  parameters:
    - key: attempts
      value: 3 # Number of retry attempts
    - key: cooldown_between_attempts_seconds
      value: 5  # Initial cooldown time before the first retry (in seconds)
    - key: cooldown_multiplier
      value: 2 # Multiplier for cooldown time
    - key: maximum_cooldown_seconds
      value: 3600 # Maximum time to wait between each retry (in seconds)

Use Case​

When calling an external API that may experience temporary failures, the Retry processor ensures reliable request execution:

RetryFailedRequests:
  processor: Retry
  parameters:
    - key: attempts
      value: 3
    - key: cooldown_between_attempts_seconds
      value: 2
    - key: cooldown_multiplier
      value: 2
    - key: maximum_cooldown_seconds
      value: 3600

This configuration retries failed requests up to three times, with an increasing cooldown time between retries to reduce system strain. This means that after the first attempt there will be a cooldown of 2 seconds, then 4 seconds and then 6 seconds. After the third attempt the request will no longer be sent to the Provider.