Workflow Retry Template

The Workflow Retry template demonstrates how BindAI can retry a failed workflow node before ultimately failing the workflow. Retry behavior is handled by the workflow executor. When a node raises an exception and a retry policy is configured, the executor attempts the node again until it succeeds or the configured maximum number of attempts is reached. This template introduces executor-level failure recovery.

Purpose

This template demonstrates how to:

configure a retry policy
retry failed node execution
limit retry attempts
continue after a successful retry
handle final workflow failure

Workflow Structure

A retry-enabled workflow can be represented as:

Start

↓

Operation

↓

Success?
   ↙       ↘
 Yes        No
  ↓          ↓
Continue   Retry Policy
             ↓
          Try Again

The retry path is managed by the executor rather than by a separate workflow branch.

Retry Policy

A workflow context can contain a RetryPolicy. Example:

from bindai_workflow.retry import RetryPolicy

policy = RetryPolicy(
    max_attempts=3,
    delay_seconds=5,
    exponential_backoff=True,
)

The policy contains:

max_attempts
delay_seconds
exponential_backoff

The current executor uses max_attempts to control retries.

Execution Flow

When a node executes successfully:

Execute

↓

Success

↓

Continue Workflow

When the node raises an exception:

Execute

↓

Exception

↓

Retry Policy

↓

Try Again

The executor repeats the node execution until it succeeds or the retry limit is reached.

Retry Lifecycle

For a policy with:

max_attempts=3

the execution can look like:

Attempt 1

↓

Failure

↓

Attempt 2

↓

Failure

↓

Attempt 3

↓

Success

If the third attempt also fails:

Attempt 3

↓

Failure

↓

Workflow Failure

Retry Counter

The workflow context tracks the current attempt using:

context.retry_attempt

The executor resets this counter before executing a node:

context.retry_attempt = 0

When the node raises an exception, the counter is incremented. The executor then checks the configured maximum:

context.retry_attempt >= context.retry_policy.max_attempts

If the condition is true, the workflow fails.

Successful Recovery

A retry can recover from a temporary node failure. For example:

Attempt 1

↓

Exception

↓

Retry

↓

Attempt 2

↓

Success

↓

Next Workflow Node

After successful execution, the executor resets the retry counter. The workflow then proceeds normally.

Retry Without a Policy

If a node fails without a retry policy:

Execute

↓

Exception

↓

No Retry Policy

↓

Workflow Failure

The executor immediately invokes normal failure handling.

Retry Limit

The max_attempts setting limits the total number of attempts. Example:

RetryPolicy(
    max_attempts=3,
)

means the node can be executed up to three times before the workflow fails. It does not mean three additional retries after the initial attempt.

Delay Configuration

The retry policy defines:

delay_seconds=5

but the current executor does not yet wait for this amount of time between attempts. The current implementation retries immediately. Therefore, this template should not be interpreted as demonstrating an actual five-second delay.

Exponential Backoff

The retry policy also defines:

exponential_backoff=True

However, exponential backoff is not currently applied by the executor. The field exists as part of the retry configuration and can support future backoff behavior. The current execution sequence remains:

Failure

↓

Immediate Retry

↓

Failure

↓

Immediate Retry

Exception Handling

The current retry implementation does not restrict retries to specific exception types. When node.execute() raises an exception:

Exception

↓

Retry Policy Exists?

↙                 ↘
No                 Yes
↓                   ↓
Fail              Retry

There is no current retry_on configuration for selecting specific exception classes.

Retry vs Loop

Retry and Loop templates solve different problems.

Retry	Loop
Responds to node exceptions	Responds to a workflow predicate
Re-executes failed node work	Intentionally repeats workflow logic
Managed by executor	Represented by a Loop node
Uses `RetryPolicy`	Uses a loop predicate
Stops on success or attempt limit	Stops when predicate becomes false

Use Retry for failure recovery. Use Loop for intentional iteration.

Retry and Timeout

Retry can be combined with workflow timeout behavior.

Workflow
   │
   ├── Timeout Policy
   │
   └── Operation
          │
          └── Retry Policy

The retry policy determines how failed node execution is handled. The timeout policy limits the total workflow execution time.

Final Failure

When all allowed attempts fail, the executor invokes normal workflow failure handling. The workflow:

records the error
marks execution as completed
records a workflow.failed event
persists the workflow instance
stores failed execution history
returns an unsuccessful workflow result

If compensation callbacks have been registered, they are also executed during final workflow failure handling.

Example Workflow

A conceptual retry workflow looks like:

Start

↓

Call External Service

↓

Exception?

↙            ↘

No            Yes
↓              ↓
Continue     Retry
                ↓
             Attempt Limit?
              ↙       ↘
            No         Yes
            ↓           ↓
         Try Again    Fail

The retry behavior is provided by the executor rather than by additional workflow nodes.

Best Practices

Set max_attempts deliberately.
Retry operations only when repeating them is safe.
Do not assume configured delay is currently active.
Do not assume exponential backoff is currently active.
Remember that all node exceptions are eligible for retry when a policy exists.
Avoid retrying non-idempotent operations unless they are designed for safe repetition.
Combine retry policies with timeout policies when appropriate.
Monitor repeated failures in production.

The Retry template works naturally with:

Workflow Parallel
Workflow Timeout
Workflow Schedule
Workflow Loop

Retry can be applied to nodes inside larger workflow structures because retry handling is implemented by the workflow executor.

Summary

The Workflow Retry template demonstrates executor-level recovery from failed node execution. When a node raises an exception and a RetryPolicy is configured, BindAI retries the node until it succeeds or max_attempts is reached. The current implementation retries immediately. Although delay_seconds and exponential_backoff are part of the policy configuration, they are not yet applied by the executor. This makes the current retry implementation a simple and predictable attempt-limit mechanism that can be extended later with delay, backoff, and more selective exception handling.

Getting Started

Core

Tools

Memory

Knowledge

Connections

Automation

Workflows

Projects

Templates

Roadmap

API Reference

08.6 workflow retry

Workflow Retry Template

Purpose

Workflow Structure

Retry Policy

Execution Flow

Retry Lifecycle

Retry Counter

Successful Recovery

Retry Without a Policy

Retry Limit

Delay Configuration

Exponential Backoff

Exception Handling

Retry vs Loop

Retry and Timeout

Final Failure

Example Workflow

Best Practices

Summary

​Workflow Retry Template

​Purpose

​Workflow Structure

​Retry Policy

​Execution Flow

​Retry Lifecycle

​Retry Counter

​Successful Recovery

​Retry Without a Policy

​Retry Limit

​Delay Configuration

​Exponential Backoff

​Exception Handling

​Retry vs Loop

​Retry and Timeout

​Final Failure

​Example Workflow

​Best Practices

​Related Templates

​Summary

Workflow Retry Template

Purpose

Workflow Structure

Retry Policy

Execution Flow

Retry Lifecycle

Retry Counter

Successful Recovery

Retry Without a Policy

Retry Limit

Delay Configuration

Exponential Backoff

Exception Handling

Retry vs Loop

Retry and Timeout

Final Failure

Example Workflow

Best Practices

Related Templates

Summary