Re-run a run after you fix it

What replay does

Replay re-executes a run you already have, using the same trigger payload. When a run fails because of a bad mapping, a misconfigured node, or a connection that needed reconnecting, you fix the workflow, then replay the original run to push the same input back through.

A replay creates a new run with its own run id. The original stays untouched as a record of what happened.

When to use it

Replay after you have already made a change that should fix the problem. Reach for it when:

• A run failed and you corrected the node, mapping, or expression that caused it.
• A step reported a retryable provider error (for example a temporary upstream outage) and you want to run the same input again now that the provider is back.
• You reconnected an integration whose token had expired, and you want the parked work to go through.

If nothing has changed since the run finished, a plain replay will reproduce the same result. Fix first, then replay.

Replay a run

1. Confirm the run is finished

   Open the run you want to re-run. Replay works only on a terminal run (completed, failed, or cancelled). If the run is still pending or running, wait for it to finish first. The auto-refresh on a run detail page polls every 10 seconds while a run is pending or running, then stops, so a finished run is not "frozen", it is simply done.

2. Apply your fix to the workflow

   Make the change that addresses the failure, then activate the corrected version. The trigger payload is re-sent as-is on replay, so the workflow logic is the only thing your fix can change. If the failure was a token problem, reconnect the integration first. See Reconnect an integration.

3. Open the Replay dialog and pick a mode

   Click Replay. The dialog is titled Replay run with the description "Re-execute this run. Pick a replay mode below." Choose one of three modes:

   • Replay as-is runs the same input through the current workflow. This is the mode you want in almost every case.
   • Replay with new prompt swaps the prompt for a specific revision. It asks for a Prompt artifact id and a Content hash, which you paste by hand.
   • Replay with new model runs against a different model. It asks for a Model id and a Model ref, which you also paste by hand.

   The new-prompt and new-model modes are operator-grade. They take raw internal identifiers, not a friendly picker, so stay on Replay as-is unless you specifically need to change the prompt or model.

4. Check the mutation banner

   The dialog always shows a banner about mutating tool calls. By default, mutating calls dry-run: the banner reads "Mutating tool calls will dry-run." A workspace can opt in per node so the replay performs real mutations, in which case the banner turns red and reads that the replay WILL invoke mutating tool calls. Read this banner before you submit so you know whether the replay will write to downstream systems or only simulate.

5. Submit the replay

   Click Submit replay. On success you get a toast reading "Replay submitted" with the new run id. Follow that id to watch the new run in the run detail view.

Resolve renamed nodes on a cross-version replay

If you replay an old run against a workflow version that renamed or restructured nodes, TaskJuice cannot tell which new node each old node maps to. The dialog shows an alert: "N renamed node(s) need mapping before this cross-version replay can run." with a Resolve mapping link.

Open it, pick the replacement node for each renamed entry, and save. Submit stays disabled until every renamed node is mapped. TaskJuice first checks for a saved mapping that already covers the renamed nodes and applies it silently if one exists, so you only do this once per version pair.

Verify it worked

A submitted replay produces a brand new run, separate from the original.

• The success toast names the new run id.
• Open that run from the run detail view and watch the step timeline. If your fix worked, the step that failed before should now reach completed.
• The original run is unchanged. Replay never edits or re-opens it.

Limits

Replay has hard limits. Each one returns a specific error if you hit it.

A replay is also rejected when the workflow itself is in the Paused (safety) state. Resume the workflow from its workflow page first, then replay. See Why a run paused for what a safety pause is and how to clear it.

Troubleshooting

You hit the replay quota. If you submit more than 20 replays in a minute within one workspace, the request is rejected. Pause for a minute and resume. If you are batch-replaying many failed runs, space them out.

The replay chain exceeded the depth limit. Each replay-of-a-replay adds one level. Past five levels, the request is rejected. Replay the original run instead of a deep descendant, or address the root cause so a single replay succeeds.

This run cannot be replayed because its source workflow version is no longer available. The workflow version the run executed against has been removed, so there is nothing to re-execute. You will see a related message if that version no longer belongs to this workflow. Rebuild the run from a current version instead.

The model is not available for this workspace. Only the new-model mode hits this. The model id you pasted is not in the workspace's allowed list, or its provider is blocked by workspace policy. Pick an allowed model, or update the workspace policy, then replay.

The Replay action is missing entirely. Replay shows up only for terminal runs. If you do not see it, confirm the run is completed, failed, or cancelled rather than still in progress.

Related

• Read a failed run to find the failing step and its error before you replay.
• Run and step statuses to confirm a run is in a replayable terminal status.
• Reconnect an integration when the failure was an expired connection.