Execution Control

Replay & Resumable Execution

Recover from failures without starting over. Rerun from a failed step, resume paused tasks, and rely on automatic retries with exponential backoff.

Rerun From Failed Step

When a workflow fails, you can trigger a rerun that starts execution from the failed step instead of the beginning. All successful step results from the previous run are preserved and injected into the context.

POST /api/tasks/:id/rerun-from-failed

# Request
POST /api/tasks/task_123/rerun-from-failed
Authorization: Bearer <token>

# Response
{
  "ok": true,
  "taskId": "task_123",
  "rerunFromStep": "step_5"
}

Resumable Execution

Tasks paused for approval can be resumed once the human decision is made. The runner continues from the next step with the preserved execution context.

POST /api/tasks/:id/resume

# Request
POST /api/tasks/task_123/resume
Authorization: Bearer <token>

# Response
{
  "ok": true,
  "taskId": "task_123",
  "status": "running"
}

Retry Behavior

Individual steps can be configured with retry policies. If a step fails, the executor retries up to the configured maximum attempts before marking the step as failed. Retries use exponential backoff.

Exponential Backoff

The initial backoff is 1 second. Each retry multiplies the wait time by the configured backoffMultiplier (default 2).

Maximum Attempts

The maxRetries field controls how many times a step is retried. The default is 0 (no retries). Retries are per-step; a successful step is never re-executed on rerun.

Step Result Preservation

On rerun, all previously successful step results are preserved. Only the failed step and subsequent steps are re-executed. This ensures deterministic behavior and saves compute.

Partial Execution

You can also trigger partial execution via POST /api/workflows/:workflowId/run-partial, which runs only a subset of steps. Combined with version history and rollback, this gives you fine-grained control over workflow experimentation.