Dova Monitor, repeat and recover an execution
Distinguish execution state, output acceptance and recovery before repeating tasks with external data effects.
On this page
Find the correct attempt
Open Monitor and adjust the period, object type, state and worker where applicable. Find the attempt ID rather than relying only on the Workflow name: an object may have several runs. Period filters change what is displayed; they do not guarantee unlimited evidence retention.
Open details to inspect tasks, times, versions, authorized parameters and available events or logs. A queued acceptance does not mean the worker has started. A succeeded state still needs independent business-result checks.
Choose an action for the observed state
| Action | Availability and required review |
|---|---|
| Open definition | Opens the associated definition. Compare the attempt’s version with any open draft. |
Download output | For a successful Mapping or Session run with an available output and authorized access. Open a Workflow’s Session task when necessary. |
| Re-run | For succeeded, failed, cancelled or terminated attempts. Starts again from the beginning with the pinned definition and corresponding input. |
| Recover | For failed, cancelled or terminated attempts with valid recovery context. Resumes work from the available recovery point. |
| Cancel | For queued work awaiting execution. |
| Terminate | For an active execution. Inspect its final state and any side effects already produced afterward. |
Availability also depends on your authorization and the current context. A missing button is not permission to recreate the operation through another route.
Investigate before retrying
- Open the attempt and identify the first failed or waiting task.
- Read its actual error, definition and version, effective parameters, worker and access to inputs or
Connections. - Check whether the target received data even though the overall attempt failed.
- Correct the cause in the appropriate configuration and determine whether a new publication or input is required.
- Choose Re-run or Recover according to what should execute again and which recovery context exists.
- Identify the resulting attempt and verify tasks, schema, rows and business rules. Preserve its relationship to the earlier attempt.
Example: an output already exists
A Session writes a CSV, then a later task fails. Repeating the whole Workflow using the same output path may overwrite or duplicate results depending on the target. In the laboratory, use an independent output and check its three records before comparing it. For an append database target, inspect keys and repeatability before launching another write.
Recover is not a distributed transaction. The recovery point and earlier commits determine which work remains persisted. Even an execution that has been terminated may have committed batches before receiving that instruction. External files and services may also have changed since the first attempt.
Accept the recovered result
- The new attempt has an ID and an explainable recovery or repetition relationship.
- Executed, skipped and reused tasks match the action chosen.
- The output satisfies its expected columns, count, keys and values, without unintended duplicates.
Worker, task and attempt states are consistent; no unknown operation remains in progress.
Waiting tasks and missing evidence
For a waiting task, inspect parents, conditions, concurrency policies, resources and worker slots. If logs or output are unavailable, check filters, permissions and retained evidence rather than inferring a result from an empty panel. Do not purge history required for investigation. For help, use the Cloudata form with version 22.0.5, the attempt ID and a synthetic example, without credentials or customer data.