What you will be able to do
- Predict which tasks a repair run re-runs, with which settings, and on which cluster
- Override parameters in the Repair job run dialog and reset them to their original values
- Recognise when repair doesn't apply (single-task jobs, disabled tasks) and what to use instead
- Repair a run from the CLI with the repair-run command and its flags
1.What a repair run re-runs, and with which settings
You can repair a failed or canceled multi-task job run. A repair runs only the tasks that did not succeed, plus any tasks that depend on them. Tasks that already succeeded are not run again, and neither are the tasks that depend only on them. That is why a repair saves time and compute compared with re-running the whole job.
You can change job or task settings before you repair, and the repair uses whatever the settings are at that point. That is what makes the diagnose → fix → repair workflow work. For example, if you change a notebook path or a cluster setting, the task re-runs with the new notebook or cluster.
There are three more things to know:
- No automatic idempotency. A repair runs each unsuccessful task again from the start. Lakeflow Jobs does not make tasks idempotent. If a task wrote some of its output before it failed, running it again can duplicate that data. Check what each task writes before you repair. Where duplicates are a concern, use idempotent operations such as overwrite or merge instead of append.
- A new job cluster. If tasks share a job cluster, the repair creates a new one. If the original run used my_job_cluster, the first repair uses my_job_cluster_v1, which has the current settings of my_job_cluster. This lets you compare the cluster settings of the original run with those of each repair.
- Duration covers every attempt. The Duration shown in the Runs tab runs from the start of the first run to the end of the latest repair. When the repair finishes, the matrix view gets a new column for the repaired run. The Task run details page keeps the history of all task runs.
Checkpoint 1 of 7· Check yourself
A task appended 40% of its rows to a Delta table and then failed. You repair the run. What happens to that task?
A repair runs the task again from the start, and Lakeflow Jobs does not make tasks idempotent. Whether duplicates appear depends on the task's own write logic, for example append versus merge.
“Lakeflow Jobs doesn't make tasks idempotent, so if a task wrote part of its output before it failed, re-running it can duplicate that data.”Source: docs.databricks.com
Checkpoint 2 of 7· Exam question
A data engineer is repairing a failed job run through the Jobs API `repairrun` endpoint and wants to correctly reason about the request before sending it. Which statements about `repairrun` behavior are accurate? (Select 3.)(Select 3)
Correct answers: A, B, F — Values supplied in `job_parameters` for the repair request take precedence over the parameter values that were used in the original failed run.; Setting `rerun_all_failed_tasks` to true tells the service to re-execute every task that did not complete successfully in the prior attempt.; Submitting `rerun_tasks` with an explicit list of task keys lets the caller target specific tasks instead of relying on the failed-task detection.
- A. Correct: parameters passed in the repair request override the values from the original attempt for the tasks being re-executed, which is exactly how the Repair job run dialog's override behavior works when driven through the API.
- B. Correct: this boolean flag reruns every task that did not succeed in the prior attempt, which is the API equivalent of letting the service auto-detect failed and canceled tasks rather than listing them manually.
- C. Incorrect: `latest_repair_id` is only required as a safeguard when repairing a run that has already been repaired at least once, so it does not need to reference anything on a run's very first repair attempt.
- D. Incorrect: task parameters can be overridden on any repair attempt, and clearing an overridden field on a later repair returns that parameter to its original value rather than the setting being locked after one use.
- E. Incorrect: a repair request only changes the parameter values used for that specific repaired run; it does not mutate the job definition's stored default parameters used by future runs.
- F. Correct: `rerun_tasks` accepts specific task keys so the caller can target exactly which tasks to re-execute, as an alternative to the automatic failed-task or dependent-task detection flags.
Sources1
2.Overriding parameters in the Repair job run dialog
Sometimes the fix is a different input rather than a code change. For example, an upstream feed published under a different date, or a parameter pointed at the wrong table. For these cases you can override job parameters when you repair a job run.
To repair from the UI, open the failed run: click its link in the Start time column, or click it in the matrix view. On the Job run details page, click Repair run. The Repair job run dialog lists every unsuccessful task and every dependent task that will be re-run. In the same dialog you can add or edit parameters for the tasks being repaired. Values you enter here override existing values. Then click Repair run in the dialog.
Overrides are not permanent. On a later repair of the same run, you can return a parameter to its original value by clearing its key and value in the dialog.
Know which kind of parameter you are dealing with. Job parameters are defaults you can override when you trigger a run. Task parameters set with static values can only be changed by updating the task definition. If the bad value is a static task parameter, edit the task first. The repair then picks it up, because it uses the current settings.
Checkpoint 3 of 7· Put it in order
Put the steps for repairing a failed run with a parameter override in order.
- 1.Enter the parameter keys and values to override
- 2.Click Repair run to open the Repair job run dialog
- 3.Click Repair run in the Repair job run dialog
- 4.Click the failed run in the Start time column or the matrix view to open Job run details
The dialog opens from the Job run details page. You enter the overrides in the dialog, and the Repair run button inside the dialog starts the repair.
“Click Repair run. The Repair job run dialog appears, listing all unsuccessful tasks and any dependent tasks that are re-run.”Source: docs.databricks.com
Checkpoint 4 of 7· Check yourself
Your first repair overrode run_date to 2025-01-02. On the second repair you want run_date back at the job's configured value. What do you do?
Clearing the key and value in the Repair job run dialog returns the parameter to its original value on later repairs. Deleting it from the job definition would remove the parameter altogether.
“you can return a parameter to its original value by clearing the key and value”Source: docs.databricks.com
Don't rely on that. The documentation describes overriding job parameters on repair. A static task parameter can only be overridden by updating the task definition. Edit the task, save it, and then repair. The repair uses the current task settings.
3.When repair isn't the tool: single-task jobs and disabled tasks
No. Repair only works for jobs that orchestrate two or more tasks. To re-run a failed single-task job, trigger it again with Run now. If you need a different parameter value, use Run now with different settings, which lets you override the default job parameters.
Disabled tasks are the second exception. A repair decides what to re-run from each task's run state, not from whether the task is disabled. A disabled task is not automatically included. To make it run during a repair, list it in rerun_tasks in the repair request. Partial runs from Run now behave the same way: the + expansion excludes disabled tasks unless you select them explicitly.
| Situation | Repair run | Run now / Run now with different settings |
|---|---|---|
| Job with two or more tasks | Supported; re-runs unsuccessful tasks and their dependents within the original run | Starts a new run |
| Job with a single task | Not supported | Use this to re-run the failed task |
| Changing parameter values | Enter overrides in the Repair job run dialog | Enter new job parameters as key-value pairs |
| Disabled task should run | Include it in rerun_tasks | Select it explicitly; + expansion excludes it |
Checkpoint 5 of 7· Check yourself
During an incident someone disabled task load_dim. It never ran, and now you want it to run in the repair of that run. What must you do?
Repair picks tasks by run state, not by disabled state. To force a disabled task to run, you name it in rerun_tasks.
“To force a disabled task to run during a repair, include it in rerun_tasks in the repair request.”Source: docs.databricks.com
4.Repairing from the Jobs API and CLI
The same repair is available outside the UI. With the Databricks CLI, databricks jobs repair-run takes the ID of the run to repair. That run must not be in progress. Repaired tasks re-run as part of the original job run, use the current job and task settings, and appear in the original run's history. For anything the flags don't cover, --json accepts the request body inline or from a file with @path.
databricks jobs repair-run RUN_ID [flags]| Flag | Meaning |
|---|---|
| --rerun-all-failed-tasks | If true, repair all failed tasks |
| --rerun-dependent-tasks | If true, also repair tasks that depend on the tasks in rerun_tasks, even if they previously succeeded |
| --latest-repair-id | The ID of the latest repair |
| --json | Inline JSON or @path to a file with the request body |
| --no-wait / --timeout | Don't wait for TERMINATED or SKIPPED, or set how long to wait (default 20m0s) |
Pay attention to --rerun-dependent-tasks. It re-runs downstream tasks even if they succeeded before. Use it when a fixed upstream task produces new output that the downstream tasks must process again.
Each repair is also recorded in the audit log as the repairRun job event. Its request parameters are run_id, latest_repair_id, rerun_tasks, rerun_all_failed_tasks, rerun_dependent_tasks and job_parameters. These are the same fields as the CLI flags above, and job_parameters carries any parameter overrides.
Checkpoint 6 of 7· Fill the gap
Which subcommand re-runs the failed tasks of an existing run inside that same run?
databricks jobs ? RUN_ID [flags]repair-run re-runs tasks as part of the original job run. run-now starts a new run, reset overwrites the job settings, and get-run-output retrieves a task's output.
Source: docs.databricks.comCheckpoint 7 of 7· Exam question
A task named `append_events` appends new rows into a Delta table with `INSERT INTO` before it fails partway through processing a large batch, leaving some rows already written. The on-call engineer plans to fix the root cause and then repair the run so only `append_events` re-executes. What should they do to avoid corrupting the downstream table?
Correct answer: A — Rewrite `append_events` to use a `MERGE` keyed on a natural identifier, or overwrite the affected partition, so repairing it again does not duplicate rows already written.
- A. A task that partially wrote its output before failing can duplicate data when it is repaired and simply reruns the same append logic; making the write idempotent through a merge on a stable key, or an overwrite of the affected partition, is the documented way to make repairs safe.
- B. Nothing about the repair mechanism inspects table contents for duplicates; the platform reruns the task's code as written, so any non-idempotent append logic will reproduce the same duplication problem on repair.
- C. A larger autoscaling ceiling changes how quickly the repaired attempt completes, but it does nothing to prevent the append logic itself from re-inserting rows that were already committed in the earlier attempt.
- D. Plain Parquet writers have no transaction log or automatic rollback of partial writes, so switching formats removes Delta's ACID guarantees entirely rather than solving the duplicate-row problem on repair.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A repair re-runs the failed task with the settings that the original run used.Why is that wrong?
A repair uses the current job and task settings. That is why you fix the task or cluster first and then repair.
Covered in What a repair run re-runs, and with which settings
2.Repairing a run is always safe because Lakeflow Jobs resumes a task where it stopped.Why is that wrong?
A repair runs each unsuccessful task again from the beginning, and tasks are not made idempotent. A task that appended part of its data before failing can write duplicates.
Covered in What a repair run re-runs, and with which settings
3.Any failed job run can be repaired, including a single-task job.Why is that wrong?
Repair only applies to jobs with two or more tasks. A failed single-task job is triggered again with Run now.
Covered in When repair isn't the tool: single-task jobs and disabled tasks
4.--rerun-dependent-tasks only re-runs downstream tasks that were skipped or failed.Why is that wrong?
It re-runs every task that depends on the tasks in rerun_tasks, including ones that succeeded before.
Covered in Repairing from the Jobs API and CLI
Practise it for real
Fix a failed multi-task job run and repair it from the Databricks CLI, re-running only the failed tasks
1.Run
databricks jobs list-runs --job-id <JOB_ID> --completed-onlyand note the run ID of the failed run.Why: repair-run needs the ID of a run that is not in progress.
You should see: A list of completed runs, newest first, including the failed one.
2.Open that run's Task run details in the UI, read the error message, and fix the cause (for example, click Edit task, correct the configuration and Save task).
Why: The repair uses the current job and task settings, so an unfixed cause will fail again.
You should see: The task configuration is saved with the correction.
3.Run
databricks jobs repair-run <RUN_ID> --rerun-all-failed-tasks.Why: This re-runs only the failed tasks, inside the original run.
You should see: The command waits (default timeout 20m0s) until the run reaches TERMINATED or SKIPPED.
4.Return to the job's Runs tab and look at the matrix view.
Why: To confirm the repair worked without starting a new run.
You should see: A new column for the repaired run, with the previously red tasks now green.
Stuck? Get a nudge
If the failed tasks write with append, check for duplicate rows after the repair. The repair ran them again from the beginning.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Because successful tasks and any tasks that depend on them are not re-run, this feature reduces the time and resources required”
↩︎ What a repair run re-runs, and with which settings“use idempotent operations (such as overwrite or merge instead of append) where duplicate data is a concern.”
↩︎ What a repair run re-runs, and with which settings“The settings for my_job_cluster_v1 are the same as the current settings for my_job_cluster.”
↩︎ What a repair run re-runs, and with which settings“The Duration value displayed in the Runs tab includes the time the first run started until the time when the latest repair run finished.”
↩︎ What a repair run re-runs, and with which settings“Parameters you enter in the Repair job run dialog override existing values.”
↩︎ Overriding parameters in the Repair job run dialog“To re-run a failed single-task job, trigger it again with Run now.”
↩︎ When repair isn't the tool: single-task jobs and disabled tasks“Repairs use each task's run state to decide what to repair, not its disabled state.”
↩︎ When repair isn't the tool: single-task jobs and disabled tasks“Unsuccessful tasks are re-run with the current job and task settings.”
↩︎ Exam trap 1“A repair re-runs each unsuccessful task from the beginning.”
↩︎ Exam trap 2“Repair is supported only with jobs that orchestrate two or more tasks.”
↩︎ Exam trap 3“Unsuccessful tasks are re-run with the current job and task settings.”
↩︎ Prediction“Lakeflow Jobs doesn't make tasks idempotent, so if a task wrote part of its output before it failed, re-running it can duplicate that data.”
↩︎ Checkpoint“Click Repair run. The Repair job run dialog appears, listing all unsuccessful tasks and any dependent tasks that are re-run.”
↩︎ Checkpoint“you can return a parameter to its original value by clearing the key and value”
↩︎ Checkpoint“To force a disabled task to run during a repair, include it in rerun_tasks in the repair request.”
↩︎ Checkpoint - 2.
“You can also override job parameters when you repair a job run.”
↩︎ Overriding parameters in the Repair job run dialog - 3.https://docs.databricks.com/aws/en/jobs/parametersOfficial docs
“Task parameters set with static values can only be overridden by updating the task definition.”
↩︎ Overriding parameters in the Repair job run dialog - 4.https://docs.databricks.com/aws/en/jobs/run-nowOfficial docs
“The + expansion excludes disabled tasks.”
↩︎ When repair isn't the tool: single-task jobs and disabled tasks - 5.
“Tasks are re-run as part of the original job run.”
↩︎ Repairing from the Jobs API and CLI“The job run ID of the run to repair. The run must not be in progress.”
↩︎ Repairing from the Jobs API and CLI“If true, repair all tasks that depend on the tasks in rerun_tasks, even if they were previously successful.”
↩︎ Exam trap 4 - 6.
“A user repairs a job run.”
↩︎ Repairing from the Jobs API and CLI