Reviews and repair
Use this guide when you must review or repair work in Agents & Workflows. Read the result to check that the change took effect.
Before you start
A review operator needs the Run, affected block, and current request. Open the Console review queue at /workflows/review for waiting Workflow decisions. Open /workflows/runs/[runId] for execution detail. Confirm that you may decide the request or control the Run. Read the approval contract for exact decision fields. Agent tool approvals have a distinct request. A Workflow block decision cannot stand in for one.
1. Inspect the stop
Review the current state before changing work. A waiting approval needs a decision. A paused Run needs its pause resolved. A failed block needs its error inspected. A quarantined event needs its delivery failure checked. Read the Run's terminal state before choosing repair. The terminal states completed, cancelled, and failed cannot be retried or resumed in place.
2. Decide the request
Review the pending subject and record the allowed decision. An Agent tool request identifies the Run, operation, registration revision, and argument hash. Its reviewer summary contains no raw argument values or secrets. Approval is not authorization: the effect still rechecks permissions, credentials, and channel rules. Read the decision back. A recorded approval alone does not prove that the call resumed or completed.
3. Repair the stop
Repair only the condition the readback names. Use the state to select the action, then read the same Run or event again.
| Current condition | Action and expected observation |
|---|---|
| Paused Run | Resolve its hold, then resume; the Run returns to running. |
| Failed block, nonterminal Run | Correct the cause, then retry the block; it returns to pending. |
| Quarantined event | Correct delivery, then retry that event; replayed confirms reinjection, not execution success. |
| Unwanted quarantined event | Discard only when that work should stop; discarded means it will not be retried. |
| Approved Agent call still paused | Have the execution owner request internal resume repair; it checks the saved decision and the same pause generation. |
Checkpoints
Review and repair must preserve the work's identity. Read the same gate, Run, block, or event after each action. A resumed Run may still fail a fresh permission check. A retried event may still lead to failed work. If a response is lost, inspect retained state before issuing another recovery action. A retry is not evidence of completion.
Success
Review succeeds when the current request shows the intended decision. Repair succeeds when the affected object shows the expected recovery state and its next result can be read. Follow the Run through to its terminal result when the goal requires finished work. A cleared review queue or delivered notice alone does not prove that the requested effect completed.
When it fails
Review failures can leave work waiting after a decision. Inspect the reported cause before retrying the decision or changing the Run.
continuation_unavailable
An Agent call could not restore the saved continuation. The decision remains unconsumed and the block stays repairable. Restore the saved execution through its owner before trying to resume. An expired or stale decision also needs a fresh matching request. Do not treat an old approval as permission for changed work.
CORE_ERROR
A Workflow decision encountered a service fault. Read the retained block and decision before trying again. Restore the failing service, then act on the current request. For a failed notification, keep using the review Task while its delivery is repaired. Missing delivery does not remove the gate or decide it.
Recovery
Review notification repair starts from the waiting gate, which owns the request. A notice failure can leave task_only coverage. An administrator can use workflows.readReviewProjection and workflows.redriveReviewProjection through the API guide. These operations have no Console wrapper. Repair reuses the gate's current revision and existing item identities. A decided gate does not recreate review work. Read the coverage again after repair.
Next steps
- Read Runs and readback to check the result after review or repair.
- Read Notifications and settings when delivery choices explain an absent notice.
- Follow Build and launch when repaired definitions need a separate Run.