Skip to content
Merulan

Inspect action runs

Inspect Action Runs to separate failed targets from effects awaiting readback, then choose the recovery each result permits.

Use this guide when an operator needs to inspect an Action Run in Company Schema. Finish with each unresolved result assigned to its retry or repair path.

Before you start

An Action Run check needs the correct Workspace, the Run, and access to its readback. The Console opens Action Runs at /schema/action-runs. Keep the target selection and intended effect in view. Actions and writeback explains accepted work and committed changes. Writeback repair needs separate access. The right to read a request does not grant its repair controls.

Read the result

An Action Run records progress over the targets frozen at launch. Read its detail before choosing a control.

  1. In Action Runs, select the Run. Check its Action, version, status, and target counts against the intended work.
  2. Inspect the chunks and last error. A running Run can show a retrying phase when a chunk is waiting for another attempt.
  3. Inspect attention items and their effect links. Use the decision table to choose the owner of the next action.
Observed resultNext action
failed or completed_with_errorsInspect failed targets before using Retry failed.
effect_accepted or effect_indeterminateFollow the owning effect's status or reconciliation readback.
cancel_requestedWait for cancellation readback before calling the Run cancelled.
Access deniedResolve access with an administrator before reading again.

Follow the effect

An Action Run can finish processing a target while that target's external effect still needs attention. Keep the effect identity with the investigation.

  1. From an attention item, follow the effect's readback link. Check the request state and correlation against the selected target.
  2. For writeback, open the request in /schema/writeback. Inspect its detail and evidence before choosing Repair or Redrive.
  3. Read the request after any permitted recovery action. Then read the affected Record to check the value the work was meant to change.

Checkpoints

An Action Run's succeeded count leaves out effects marked accepted or indeterminate. Check those items even when no target remains running. Retry failed uses failed targets from the same frozen source. It cannot repeat an uncertain effect. Cancel run asks the Run to stop while work can still proceed. Read the result before treating the Run as cancelled.

Success

An Action Run check succeeds when its counts and effect readback explain the outcome. Successful targets have confirmed results. Failed targets have a known cause and a permitted repair. Accepted or indeterminate effects stay open until their owner resolves them. Keep the Run and effect ids when handing unresolved work to another operator. That person can then resume from the same evidence.

When it fails

effect_indeterminate

An Action Run cannot confirm whether the effect completed. Read the owning effect's status or reconciliation result before any repeat. The attention item is not counted as success and is not a retryable failed target.

manual_review

A writeback request is parked for an operator decision. Check whether durable redrive context exists. Redrive stays unavailable when that context is missing, because the local resolution cannot be reconstructed from the parked request.

Recovery

An Action Run retry and a writeback redrive solve different failures. Use Retry failed only after the Run ends with failures. For a parked write with durable context, Redrive finishes local work. It does not repeat the external call. Supply the observed outcome when readback mode needs it. Repair records a chosen state change. Force-commit marks the request committed without rerunning local work. Check the evidence before using that repair.

The Console explains sign-in and Workspace selection for this Action Run path. The API reference page covers definitions, migrations, and Saved Queries. It supplies no Action Run or writeback call contract.

Next steps