Section 9 is Debugging and Deploying. The deploying half is Declarative Automation Bundles — deploying Databricks as code / Git Folders & CI/CD — version control inside the workspace; this is the debugging half — when something fails, where you look, and how you recover without redoing everything.

The spine

Beat 1 — the anchor: find the cause, then re-run only what broke

Anchor. Debugging is two moves. (1) Locate the cause with the right diagnostic surface (The monitoring map — which surface answers which question) — a stack trace in the driver log, skew/OOM in the executor logs and Spark UI, a slow query in the Query Profile, "who/what ran" in system tables. (2) Recover surgically — fix the cause, then repair the run so only the failed task (and its downstream) re-executes. Never re-run the whole job when one task broke.

Beat 2 — job repair: re-run only the failure

A multi-task job runs 2 hours; the final task fails.

Predict: you fixed the cause. Do you re-trigger the whole job from task 1?

…

No — Repair run. It re-executes only the failed task and its downstream dependents, reusing the successful upstream results (recall Jobs & orchestration — multi-task, dependencies, control flow: no cross-task rollback, so the good tasks are already committed). Full re-run wastes the 2 hours and risks duplicate work.

Beat 3 — parameter overrides on a repair (the tested nuance)

The Repair run dialog lets you change a parameter before re-running.

Predict: you override a task parameter in the repair dialog. Does that change the job's saved config for future runs?

…

No. The override applies only to this repair run — the job's stored parameters are untouched. So the pattern for "a task failed because of a bad/missing parameter": repair the run with the corrected parameter (and, if the parameter was missing entirely, also add it to the task definition so future runs have it). You can likewise override a failed task's cluster config on repair — e.g. point task Y at a permitted instance type — and Databricks re-runs just Y.

Lock it. Fix cause → Repair run (only failed + downstream re-run). Overrides in the repair dialog (parameter or cluster) apply only to that run, not the saved job.

The dials (skim now; return when a question needs one)

◆ Recover programmatically — the Jobs API sequence

To automate monitoring + recovery (Jobs via REST API and CLI): jobs/list (find the job) → jobs/runs/list (check statuses, find the failed run) → jobs/run-now to re-trigger (or jobs/runs/repair to repair just the failed tasks). "Automate: list jobs, identify a failed one, rerun it" → that list → runs-list → run-now sequence.

◆ Reading the evidence

• Query Profile → Top Operators — for a slow query, the highest-cost operator names the culprit (e.g. a BroadcastNestedLoopJoin = an accidental cross/inefficient join). Same tool as Reading the evidence — Query Profile & Spark UI, here to diagnose not just tune.
• Parsing logs — to pull key signals out of raw Spark/driver log text, regex is the tool (grep-style pattern matching over log lines).
• Cluster / executor logs + system tables — driver log for the stack trace; executor logs for skew/OOM spikes; system.access.audit / system.compute.* for who-ran-what and resource history (System tables — the account's durable, queryable memory).

◆ Streaming failure recovery

A streaming job that must recover automatically on failure wants New Job Cluster + unlimited retries + max concurrent runs = 1 (isolated, auto-restart, never two copies fighting one checkpoint — recall Structured Streaming & the state model). And if a streaming query's state/checkpoint is corrupt or the logic changed incompatibly, the fix is to point it at a new checkpointLocation (start fresh) rather than fight the old state.

Takeaways (rebuild it from these)

1. Debug = locate the cause (right diagnostic surface) → recover surgically (repair only what failed).
2. Repair run re-executes only the failed task + downstream — never re-run the whole job for one failure.
3. Overrides in the repair dialog (parameter or cluster) apply only to that run; if a parameter was missing, also add it to the task for future runs.
4. Automate recovery via jobs/list → jobs/runs/list → run-now/repair.
5. Diagnose with Query Profile Top Operators (slow), regex (log parsing), cluster/executor logs + system tables (errors/resources). Streaming auto-recovery = new cluster + unlimited retries + max-concurrent-1; corrupt state → new checkpointLocation.

Before you move on — say these without scrolling up

1. Final task of a 2-hour job failed — how do you re-run, and what does it re-execute?
2. You override a parameter in the repair dialog — does it change the saved job?
3. Automate "find the failed job and rerun it" — the API sequence.
4. Slow query — which panel names the culprit operator? Corrupt streaming state — the fix?

Next: the pipeline-specific half — debugging Lakeflow Declarative Pipelines → Debugging Lakeflow Declarative Pipelines.