Workflows now supports delay functions when retrying
Key Points
- retries.delay accepts a function
- Function receives ctx and error
- Return string, number, or Promise for duration
Summary
Workflows step retries can now accept a dynamic delay function via retries.delay. Instead of only fixed durations and static backoff strategies (constant, linear, exponential), you can supply a function that computes the next delay based on the retry context and the thrown error. This enables adaptive retry timing (for example, longer waits for rate-limit errors and shorter for transient network glitches) and can consume downstream guidance such as Retry-After headers.
Key Points
- Use
retries.delay: ({ ctx, error }) => …to compute delays dynamically. - The delay function may return a duration string (e.g.
"10 seconds"), a number, or a Promise that resolves to a duration. - You still have existing backoff options, but delay functions let you add conditional logic (e.g.
if (error.message.includes("rate limit")) return${ctx.attempt * 30} seconds;). - Practical uses: respect API
Retry-After, escalate wait times for rate limits, shorten waits for transient errors, or implement custom per-provider retry policies. - This avoids adding external queueing/scheduling just to vary retry timing.
See the "Sleeping and retrying" docs for exact duration formats and runtime behavior.