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

# Retry policies

> Retry an eligible failed task within the same run. The controller owns the retry decision and saves the policy and delay so a restart does not create a new retry budget.

How-to guideApplies to: Unified engine deployments

Retry an eligible failed task within the same run. The controller owns the retry decision and saves the policy and delay so a restart does not create a new retry budget.

## 1. Configure a bounded policy

This read-only workload uses a task override with three total attempts, a five-second initial delay, exponential backoff, and no jitter. It normally succeeds on the first attempt.

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "name": "Learn - task retry policy",
  "tasks": [
    {
      "name": "summarize",
      "sql": "WITH orders(id, category, region, amount) AS (\n  VALUES\n    (1, 'Books', 'North', 20),\n    (2, 'Games', 'South', 30),\n    (3, 'Games', 'North', 15),\n    (4, 'Books', 'North', 40),\n    (5, 'Garden', 'South', 25),\n    (6, 'Garden', 'North', 10)\n)\nSELECT SUM(amount) AS sales FROM orders;",
      "settings": {
        "current_catalog": "default",
        "namespace": [
          "default"
        ],
        "time_zone": "UTC",
        "case_sensitive": false,
        "ansi_enabled": true
      },
      "control": {
        "retry": {
          "max_attempts": 3,
          "initial_delay_seconds": 5,
          "max_delay_seconds": 30,
          "backoff": "exponential",
          "jitter_percent": 0,
          "python_replay_safe": false
        }
      }
    }
  ],
  "dependencies": [],
  "options": {
    "execution_target": "DuckDb"
  },
  "policy": "Manual"
}
```

Open the task's **Retry policy** settings to inspect the override. Save as Manual, run it, and confirm that success ends execution immediately. An attempt budget is a limit, not a request to repeat a successful task.

## Understand the fields

| Field | Meaning |
| - | - |
| `max_attempts` | Total attempts, including the first execution. Range: 1–100 for a task override. |
| `initial_delay_seconds` | Positive delay after the first eligible failure. Default: 5. |
| `max_delay_seconds` | Delay cap, at least the initial delay and at most 86,400 seconds. Default: 300. |
| `backoff` | `fixed` or `exponential`. Omitted API value defaults to `fixed`. |
| `jitter_percent` | Bounded spread that reduces the nominal delay by up to this percentage. Range: 0–100; default: 0. |
| `python_replay_safe` | Explicit permission to repeat an eligible batch Python program. Default: false. |

With the example's policy, failures after attempts 1 and 2 are followed by delays of 5 and 10 seconds. There is no fourth attempt. A larger attempt budget still respects the maximum delay.

The editor's new-override preset uses three attempts, exponential backoff, and 10 percent jitter. These UI starting values differ from omitted API field defaults. Review the complete saved policy.

Without a task override, the task inherits the workload's resolved attempt limit. Setting an override's `max_attempts` to 1 disables further attempts for that task.

## Know what can retry

A retry needs both a retryable failure and execution that the engine can safely repeat. Invalid SQL, definition errors, and uncertain write outcomes do not become retryable just because the attempt limit is high.

Read-only queries can be eligible. Writes require supported coordinated commit and recovery behavior. Some commands and connectors cannot be replayed automatically. The engine checks the execution program and connector rules.

Python can have external effects. Enable **This Python task is safe to repeat** only when repeating the whole program is acceptable. This flag does not make external calls idempotent or bypass uncertain-outcome protection.

## Inspect a retry

After an eligible transient failure, inspect the failed attempt, WaitingRetry phase, and the next attempt's number. Keep the same workload run ID throughout the comparison. The final task state reflects the completed outcome after the applicable policy.

Do not deliberately break SQL to test transient retry behavior. A parser failure is a permanent error. Use actual transient failure evidence or a controlled test environment when checking recovery behavior.

## Choose a different recovery action

Retry does not change code, parameters, or the recorded run definition. To use corrected current code, create a new run. To repeat selected tasks with the earlier invocation, use [Selective reruns](https://docs.e6data.com/transformation/workloads/reruns.md).

When a write is OutcomeUnknown, inspect the original attempt and commit evidence before starting replacement work. See [Results and table commits](https://docs.e6data.com/transformation/workloads/results-and-commits.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.