# Recover a complete workflow run

A Rewind run groups up to 100 completed actions from one sequential business workflow. It can span several configured HTTP APIs and Supabase projects. Record the history, close it, review the complete plan in Rewind, and approve once. Workers recover supported steps in reverse order, one at a time.

Recovery is not an atomic transaction across services. If step 3 restores and step 2 conflicts, step 3 stays restored and step 1 remains blocked. Rewind keeps the reports and does not automatically resume a stopped run.

## Before you connect a real workflow

Use disposable records first. Each service needs a compatible provider adapter and a trusted recovery worker. HTTP records require strong ETags and atomic If-Match updates. Supabase rows require the Rewind connector installer and an explicit table/field allowlist. The existing adapters support updates of existing, non-null, top-level scalar fields. They do not reverse arbitrary n8n nodes, sent emails, payments, record deletion, or unrecorded changes.

Choose a connection name for each service, such as `crm` or `access`. Use the same name in the operation and its worker. The name is a routing label within your client workspace, not a permission boundary. Configure the endpoint and credentials in the worker; never include them in the recorded resource or run metadata. Existing integrations without a connection name use `default`.

## Record every completed action

Generate one stable run ID in the parent workflow before its first action. Pass it to all calls of the recording subworkflow. Do not generate a new run ID or action idempotency key when retrying a recording delivery.

1. Read the target fields and the provider's version immediately before changing them.
2. Use a conditional write to prevent a concurrent edit from being overwritten.
3. Verify that the write succeeded and retain its resulting fields and new version.
4. Submit the operation to `POST /api/v1/operations` with a Rewind **recording** key. Only retry this recording request, with the exact saved payload, if delivery fails. Do not repeat the provider write.

```json
{
  "idempotencyKey": "onboarding-2048-action-1",
  "title": "Update customer plan",
  "kind": "conditional_http",
  "connection": "crm",
  "resource": "customer_2048",
  "before": {"plan": "starter", "seats": 5},
  "after": {"plan": "team", "seats": 20},
  "beforeVersion": "\"version-1\"",
  "afterVersion": "\"version-2\"",
  "run": {"id": "onboarding-2048", "name": "Customer onboarding", "step": 1}
}
```

Keep the run name identical on every step. Steps must be consecutive integers starting at 1; one operation represents one completed action. Run IDs accept 8–100 letters, digits, hyphens or underscores. An operation retry must match its original payload. A different action cannot reuse an existing step.

Record irreversible actions with `kind: "irreversible"` and meaningful before/after scalar snapshots. No automatic recovery will be attempted for them. A person must review each one before approval; acknowledging it does not reverse its effect.

If the same record changes twice in a run, the later action's `beforeVersion` must equal the earlier action's `afterVersion`, and their overlapping field snapshots must agree. Without a continuous version chain, the run cannot be approved. During recovery, Rewind passes the newly restored version from the later step to the earlier step's worker; the original versions stay unchanged in the audit history. An external edit between those restores still causes a conflict.

## Close the complete history

Stop the original execution before closing its history. Ensure every completed side effect has been recorded, including any successful actions before a forward failure. Do not close a run while writes are still in flight or an outcome is unknown. Inspect the provider and reconcile missing history first; Rewind cannot discover omitted actions by itself.

Call the **run completion workflow** from n8n with the following input, or send it directly to `POST /api/v1/runs/seal` with your recording key:

```json
{"id":"onboarding-2048","stepCount":3,"recordingComplete":true}
```

The final count must match a complete sequence of recorded steps. Sealing closes the run to new actions and is safe to retry with the same count. It does not approve recovery. For another execution, use a new run ID. Parallel branches need a reconciled complete order; Rewind does not infer a dependency graph.

In n8n:

- Prepare templates in **Connect n8n**, once for each named service connection.
- Import and publish the generic recording subworkflow. Its trigger accepts the incoming operation; call it using Execute Sub-workflow after each verified action. It supports HTTP, Supabase and irreversible records. An incoming `connection` overrides its configured default.
- Import and publish the run completion subworkflow. Configure its Rewind address and select the same recording Header Auth credential on **Seal workflow run**. Call it only after the complete history is known.
- The Supabase capture download is a manual, single-record example. In your business workflow, use the connector's read/capture RPCs and pass their captured values to the generic recorder.
- Configure and publish a recovery worker for each connection. The exported schedule claims one eligible step each minute. Multiple workers cannot skip a later dependency. A worker for `crm` cannot claim an `access` job.

## Review, approve and verify

Open **Workflows → Workflow runs**. Select the run, inspect every affected record, and review irreversible actions. **Preview full recovery** retrieves a fresh plan. Approval requires the displayed run revision to remain current and atomically queues all recoverable steps. A recording or worker key cannot approve it.

Keep every required worker running. Each step checks the current provider version and changed fields before writing, and reports its outcome. Refresh Rewind to see progress. Verify the final records in the connected services before restarting business work.

A conflict, rejected write, manual outcome, unknown outcome or expired worker lease stops the remaining steps. A late report can clarify what happened, but does not automatically resume the run. There is no force-undo or resume control. Inspect the provider and original execution, then handle any further correction deliberately.

For a Node worker, set `REWIND_CONNECTION=crm` alongside its existing endpoint and key configuration. Give each worker process its own private journal. Recording custom code or AI-agent actions uses the same HTTP contract; those callers still cannot approve their own recovery.

## History and access

Runs belong to the signed-in account. Run metadata and every operation are included in account export and removed by account deletion. Existing independent operations remain under **All changes**. Provider secrets, worker keys and lease secrets are excluded from exported history.

Authenticated browser endpoints are `GET /api/runs`, `GET /api/runs/:id/preview` and `POST /api/runs/:id/undo`. The approval body contains the preview's `revision` and a stable `requestId`; it requires the session and CSRF token. Keep that request ID unchanged when retrying a lost approval response. The run list returns at most 25 entries and an optional `nextCursor`, used as `?before=<cursor>`.