Resilience icon

Resilience

Retry, concurrency, and dead-letter utilities for workflows

Actions6

Retry Strategy → Evaluate

AI-generated

Summary

Evaluate each input item for a failure signal and route it to Success, Retry, or Exhausted. Retryable items receive a __retry metadata object with the next attempt number and a calculated delay; the operation does not wait or retry the item itself.

Inputs

  • Max Attempts — Maximum retry attempts (default 3). The current count is read from Attempt Field; reaching the limit exhausts the item.
  • Strategy — Delay calculation: exponential, fixed, or linear (default exponential).
  • Base Delay Seconds — Base for the retry delay calculation (default 5 seconds).
  • Max Delay Seconds — Caps the calculated delay before jitter (default 300 seconds).
  • Enable Jitter — Randomizes the delay around the calculated value (default enabled).
  • Jitter Percentage — Jitter range as a percentage (default 30); shown and used when jitter is enabled.
  • Retry Status Codes — Comma-separated status codes treated as retryable (default 408,429,500,502,503,504).
  • Stop Status Codes — Comma-separated status codes treated as permanent failures (default 400,401,403,404). Other HTTP status codes of 400 or higher are also treated as permanent.
  • Status Code Field — Dot path to the input status code (default statusCode). A code of 400 or higher signals failure.
  • Error Message Field — Dot path to an error message (default message). A non-empty message signals failure when no status code is present and can trigger retry.
  • Attempt Field — Dot path to the current attempt count (default __retry.attempt); missing or invalid values count as zero.
  • Preserve Original Item — When enabled (default), retains the input JSON and binary data while adding metadata. When disabled, outputs only the metadata JSON.

Output shape

Three main output branches: Success, Retry, and Exhausted; each contains the corresponding input items with __retry metadata when processing succeeds.

Each metadata object includes shouldRetry, attempt, maxAttempts, strategy, delaySeconds, reason, and exhausted. Items without a failure signal go to Success. A configured stop code or other HTTP code of 400 or higher goes to Exhausted; a retryable failure goes to Retry unless the current attempt has reached Max Attempts. Delay is calculated for Retry items, rounded to whole seconds, and jitter is applied after the maximum-delay cap, so the final value may exceed that cap. The node only classifies and annotates items; it does not schedule a wait or perform another attempt. Per-item errors go to Exhausted when Continue On Fail is enabled; otherwise execution raises an error.

Links

Discussion