> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bindai.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 06.7 retry

# Retry Policies

Retry policies improve workflow reliability by automatically repeating failed operations.

Instead of immediately failing a workflow when a temporary error occurs, BindAI can retry the operation according to a configurable policy.

Retries are commonly used for transient failures such as network interruptions, temporary API outages, or rate limits.

***

# What is a Retry Policy?

A retry policy defines how BindAI should respond when an operation fails.

Conceptually:

```text theme={null}
Execute Task

↓

Success?
      ↙       ↘

    Yes       No

              ↓

          Retry Policy

              ↓

        Execute Again
```

If the operation eventually succeeds, workflow execution continues normally.

***

# Why Use Retries?

Many failures are temporary rather than permanent.

Examples include:

* network timeouts
* temporary service outages
* rate limiting
* database connection failures
* cloud service interruptions

Automatically retrying these operations often avoids unnecessary workflow failures.

***

# Retry Lifecycle

A retry-enabled operation follows this pattern.

```text theme={null}
Attempt 1

↓

Failure

↓

Wait

↓

Attempt 2

↓

Failure

↓

Wait

↓

Attempt 3

↓

Success
```

If all attempts fail, the workflow reports an error.

***

# Retry Policy Configuration

BindAI provides a retry policy object.

Typical configuration includes:

* maximum attempts
* delay between attempts
* exponential backoff

Example:

```python theme={null}
RetryPolicy(
    max_attempts=3,
    delay_seconds=5,
    exponential_backoff=True,
)
```

***

# Maximum Attempts

The retry policy limits how many times an operation may execute.

```text theme={null}
Attempt 1

↓

Attempt 2

↓

Attempt 3

↓

Stop
```

Once the maximum number of attempts is reached, no further retries occur.

***

# Retry Delay

Retries usually wait before executing again.

```text theme={null}
Failure

↓

5 Seconds

↓

Retry
```

A short delay prevents immediately repeating the same failing operation.

***

# Exponential Backoff

Instead of using the same delay every time, exponential backoff increases the waiting period after each failure.

Example:

```text theme={null}
Attempt 1

↓

5 Seconds

↓

Attempt 2

↓

10 Seconds

↓

Attempt 3

↓

20 Seconds
```

This reduces pressure on overloaded services and improves recovery chances.

***

# Success During Retry

If a retry succeeds, workflow execution continues normally.

```text theme={null}
Attempt 1

↓

Failure

↓

Retry

↓

Success

↓

Continue Workflow
```

The workflow behaves as though the operation had succeeded on the final attempt.

***

# Permanent Failures

Retries cannot fix permanent problems.

Examples include:

* invalid credentials
* incorrect configuration
* invalid input
* missing resources

These failures should be corrected rather than retried repeatedly.

***

# Retry vs Loop

Retries and loops serve different purposes.

| Retry                   | Loop                    |
| ----------------------- | ----------------------- |
| Handles failures        | Repeats business logic  |
| Automatic               | Workflow controlled     |
| Triggered by exceptions | Triggered by predicates |
| Reliability feature     | Process feature         |

Retries recover from transient errors.

Loops intentionally repeat workflow execution.

***

# Retry Use Cases

Retry policies are commonly applied to:

* API requests
* database operations
* cloud services
* document indexing
* external integrations
* AI model providers
* network communication

These systems occasionally experience temporary failures that recover automatically.

***

# Error Handling

When all retry attempts fail, workflows can:

* terminate execution
* route to an error handler
* notify administrators
* create a human task
* schedule another execution

Retry policies work well when combined with broader error-handling strategies.

***

# Best Practices

* Retry only transient failures.
* Limit the maximum number of attempts.
* Use exponential backoff for external services.
* Log retry attempts for troubleshooting.
* Avoid retrying invalid requests.
* Combine retries with timeout policies where appropriate.

***

# Summary

Retry policies improve workflow resilience by automatically repeating failed operations.

They reduce failures caused by temporary infrastructure problems while preventing unnecessary workflow interruptions. Properly configured retries make AI workflows significantly more reliable in production environments.