Core Concepts
Replay

Replay

Replay re-drives one item that didn't work — through your current code, into a new run linked to the original via replayed_from. The original is never mutated.

For an incident rather than an item — "re-drive everything that broke for this tenant last night" — reach for Recovery, which takes a predicate over a window instead of an id. Replay is the single-item verb; papayya release is the cohort one, and they share a lineage model.

How replay works

Every item carries its outcome (ok / degraded / failed), a full step trace, and its cost. papayya replay <id> mints a new run whose replayed_from points at the original and re-drives that item through your current code.

Within the replayed item, completed steps replay from cache (see Durability); only the work that didn't finish re-executes.

When to use replay

  • A single item — one customer reports bad output on one document. Fix, then replay that item.
  • A transient failure — a provider blipped on one item. Replay it.
  • A whole incident — use papayya release instead. Re-driving 40 items one id at a time is not the shape of the problem.

Triggering a replay

CLI

papayya replay <run_id>                 # re-drive the item
papayya replay <run_id> --latest        # on the agent's CURRENT version
papayya replay <run_id> --tenant acme   # only if the item's partition matches
papayya replay <run_id> --force         # re-drive even a item that worked

Only a terminal item (completed / failed / quarantined) can be replayed — an in-flight one has no captured result to re-drive against. By default only an item that didn't work is eligible; --force overrides that.

--latest re-runs on the agent's current version. Without it, the replay re-runs on the version the original captured; an item whose captured version differs from the current one is refused rather than silently re-run on different code. Items predating version capture replay on latest.

Dashboard

Open an item and click Replay. The action creates a new run linked back via replayed_from. For a whole cohort, use Recovery in the sidebar.

Replay creates a new run

Replay never modifies the original. It mints a new run with a new id, linked to the source through replayed_from, and re-drives the item into it. The original remains unchanged for audit purposes. Follow the replayed_from chain in the dashboard to see how an item was recovered over successive passes.

The item, the run, and this route's name

POST /v1/durable/runs/{runID}/replay takes a item id, not an invocation id — the path parameter's name predates the vocabulary and the route is published, so it keeps its name and its meaning. The cohort verbs live at /v1/durable/cohorts precisely so that no path segment has to mean two different nouns.