FAQ¶
Why is the Resume button missing on my Sync, Export, or Materialize Run?¶
By design. Sync, Export, and Materialize cannot pick up from where they stopped: each one operates on units of work that have to be re-applied in full to remain consistent. Aborted or failed Runs of these operations expose Rerun instead, which starts the operation from scratch. Profile, Scan, and Promote do support Resume because they track per-container progress and can continue processing only what was left.
What happens to partial results when a Run is Aborted?¶
Partial results are preserved. Anomalies already written, containers already profiled, computed data already materialized, and any other work the Run completed before the abort remain in the system. The Run lands on Aborted with summary metrics reflecting only what was finished. Resume (where supported) continues with the unprocessed containers; Rerun starts the operation over from scratch.
What happens to a Run that was interrupted by a Dataplane restart?¶
It recovers on its own. When the Dataplane comes back, the platform automatically restarts the Runs that were in progress: Profile, Scan, and Promote continue with the work that had not been processed yet, while Sync, Export, and Materialize start over from the beginning. The one exception is External Scan, which is aborted instead. To scan the data again, start a new External Scan.
The automatic recovery is capped. If the same Run keeps triggering a Dataplane restart, the platform stops retrying it after three automatic restarts (the default limit for a deployment) and marks the Run as Failure, with a message stating that it failed after that many automatic restarts. This protects the platform from an operation that itself crashes the engine, which would otherwise restart forever, and it points you at the Run to investigate instead.
A capped Run is not stuck. Rerun or Resume it yourself once you have looked into the cause: a restart you initiate is a deliberate retry, so it starts with a fresh automatic-restart budget.
What is the "Warning: Completed with logs" indicator next to a Run ID?¶
It is not a separate status. The badge stays Success (green) and the Run is treated as a terminal Success everywhere it counts (Auto-Resolve, summary metrics, downstream consumers). The icon next to the Run ID only signals that the Run recorded log entries during execution, usually because individual containers raised warnings or partial issues. Open the operation log from the expanded Run to review the entries before relying on the result.
Can I delete a Run while it is Running or Queued?¶
No. The Delete button is only available after the Run reaches a terminal state (Success, Failure, or Aborted). To stop an in-progress Run, use Abort; once it lands on Aborted, Delete becomes available.
Does deleting a Run also remove the anomalies it created?¶
It depends on the operation type. Delete removes the Run's record from the Activity list. Deleting a Scan or External Scan also permanently deletes the anomalies it found, recalculates quality scores, and makes the previous successful scan the latest one when the deleted Run was the latest. Deleting a Profile removes its profile results and, when it was the latest profile, makes the previous successful profile the latest one. Data written by Sync, Export, Materialize, and Promote stays in place.
Why can External Scan only be Aborted?¶
External Scan validates the data you provide for that run (an uploaded file, or records sent through the API) against the container's checks, and it supports neither Resume nor Rerun. To scan a file again, start a new External Scan. You can still Abort an External Scan that is queued or running, and Delete it once it lands on a terminal state.
What permission do I need to take actions on a Run?¶
The Editor team permission on the target datastore lets a user Abort, Resume, and Rerun any Run against that datastore, and Delete the Runs they started. Viewer, Reporter, and Drafter cannot act on Runs. The Admin user role bypasses team-permission checks and can delete any Run.
See also:
- Runs Permissions: full team-permission matrix.
- Operation-specific Permissions pages: Scan Permissions and Promote Permissions, for permissions that go beyond Run actions (configuring the operation, scheduling).
Where do I see logs for a failed Run?¶
The operation log is reachable from the expanded Run row. Run-level errors (setup, scheduling, platform failures) live in the Run-level log; per-container errors live alongside each container row inside the expanded Run.