Reliability and Recovery
Valdr Workflows are designed for work that outlives one terminal session. Runs keep their progress in your local workspace, preserve earlier attempts, and resume from explicit waits instead of reconstructing state from chat history.
Stable workflow versions
A run stays tied to the workflow versions selected when it starts, including the versions of any child workflows. Editing or importing a newer version does not alter an existing run.
Use Run again when you want another run with the same behavior. Select the newer definition explicitly when you want the updated process.
Durable progress
Valdr records step progress before advancing. If Valdr restarts while a run is waiting, blocked, or between steps, the run remains available with its prior attempts and can continue from the recorded state.
This is especially useful for workflows that span agent sessions, independent reviews, and human approval gates.
Evidence before advancement
Workflows can require evidence before moving on:
- A launched agent session reached its expected result.
- An assigned reviewer published a supported verdict.
- A child workflow completed and returned its declared outputs.
- An authorized operator approved or rejected a human gate.
The run inspector shows the accepted evidence and links to related Valdr records so you can understand why the workflow advanced.
Controlled recovery
Valdr offers only recovery actions that match the current run and step state:
| Action | Use it when |
|---|---|
| Step | You want to advance one ready transition and inspect the result |
| Run until wait | Advance up to ten ready transitions, stopping sooner for input, a wait, or a closed run |
| Retry step | A supported blocked or failed step can be attempted again safely |
| Run again | A completed, failed, or cancelled root run should be repeated separately |
| Cancel run | Stop workflow orchestration; see cancellation scope for how this affects related work |
| Delete run | A blocked, failed, completed, or cancelled run tree and, by default, its linked sessions should be permanently removed |
Retrying adds a new attempt and keeps the previous one. Running again creates a separate history. Neither action rewrites what already happened.
If Run until wait reaches its ten-operation limit while ready work remains, choose it again to continue.
Pending, running, and waiting roots or children must be cancelled before deletion. Delete run has no restore path and deletes linked session records, events, transcripts, and session-owned worktrees by default; select Keep linked sessions to preserve them.
Cancellation
Cancel run stops orchestration for the selected run and its active child runs, closes their open waits, and requests cancellation of in-flight commands and agent sessions launched by those runs.
Pre-existing sessions that a workflow continues or waits on remain independent. Cancelling the workflow does not stop those sessions merely because they are linked to it. For example, a workflow that sends input to an existing session can be cancelled while that session continues running.
Provider-side or externally started work may continue after the cancellation request. Check the linked session and use its session or provider controls to stop any remaining work you intend to end.
Human authority stays explicit
Review verdicts and human approvals are separate. A reviewer can publish review_approved or review_changes_requested; an operator can choose approved or rejected at a human gate. One cannot silently substitute for the other.
Local control
Local-first: Workflow definitions, runs, attempts, evidence, and history live in your local Valdr workspace and remain until you explicitly delete them.
Next step
Use the Workflow UI run inspector to see these recovery controls in practice.