Finding and handling where a DAG run actually failed
When a dbt run fails partway through the DAG, dbt provides several tools to diagnose the failure and efficiently resume execution without rerunning successful models. Understanding error types, state-based reruns, and the run_results.json artifact is essential for managing failure points in production pipelines.
1 · Learn the must-know
- dbt distinguishes between compilation errors (caught before execution, e.g. Jinja/SQL syntax issues) and database errors (raised by the warehouse during model execution, e.g. type mismatches or permission issues), both shown in the CLI output with the failing model name.
- When a model fails, dbt marks all downstream dependent models as 'skipped' rather than attempting to run them, since their inputs would be invalid or missing.
- The
dbt run --select result:error+ --state path/to/artifacts(orresult:error) pattern uses the previousrun_results.jsonto rerun only models that errored (and optionally their downstream dependents), avoiding a full pipeline rerun. - Similarly,
--select result:skippedcan be used to rerun models that were skipped due to an upstream failure, after the root cause is fixed. - Tests failing (as opposed to models failing) produce a 'fail' or 'warn' status but do not block downstream models from running unless configured with
error_if/severity settings or the models are explicitly selected based on test results. - Common root causes of DAG failure points include schema/column changes upstream, missing or stale source data, hard-coded references instead of
ref()/source()breaking lineage, and warehouse-level issues like permissions, timeouts, or credit/resource limits.
2 · Check your understanding
A model's schema.yml contains:
models:
- name: stg_customers
columns:
- name: customer_id
tests:
- not_null:
config:
severity: error
The test currently fails on three rows because of a known, temporary upstream data issue that the source team is fixing next week. You want dbt build to keep running the rest of the DAG (and still clearly report the failure) without stopping on this test. Which change accomplishes this with the least disruption?
What you have tried across dbt Analytics Engineering's objectives, not a readiness score.
Developing and optimizing dbt models45.16% of the exam*0 of 14 tried
Managing dbt models governance9.68% of the exam*0 of 3 tried
Debugging data modeling errors16.13% of the exam*0 of 5 tried
Troubleshooting and optimizing dbt pipelines6.45% of the exam*0 of 2 tried
Implementing dbt tests9.68% of the exam*0 of 3 tried
Implementing and maintaining external dependencies6.45% of the exam*0 of 2 tried
Leveraging the dbt state6.45% of the exam*0 of 2 tried
* Our estimate. dbt Labs publishes no section weights.
3 · Keep going
Ready for more? Take a weighted mock or try free practice questions.