dbt+build+failed+error+compilation+error+test+depends+on+missing

Not specified by the original author.

TL;DR

Fix the reference, not the test: a test that depends on a missing model ref means the generic or singular test is attached to a model name that does not exist in the project, usually after a rename or a moved file. dbt compiles tests against the manifest graph. A ref to a renamed or deleted model fails the whole build at compilation, before any test runs.

dbt build failed error "compilation error: test depends on missing model ref"

Use this when

• The check or run fails with this symptom: a dbt build fails with compilation error test depends on missing model ref.
• You are working on a dbt project where a build fails at compilation after a model rename or restructure and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A source reference that is missing because the source definition was removed, which needs the source restored rather than a model ref fix.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Read the compilation error for the exact missing ref name and the file that references it. Verify: the dangling reference is located
2. Search the project for the model file and for the old and new names. Verify: the rename or deletion that orphaned the test is confirmed
3. Update the test attachment to the current model name, or restore the model if it was deleted by mistake. Verify: dbt parse completes with no missing ref errors
4. Run dbt build for the affected model and its tests. Verify: the build compiles and the tests execute
5. Run a full dbt parse in CI so future renames fail at review time. Verify: parse is part of the project checks

Variant phrasings

dbt compilation error test depends on missing model ref

The shorter phrasing focused on the named failure.

dbt build failed missing model ref test

The symptom phrasing a searcher tries next.

dbt test ref model renamed compilation fix

The variant naming the failing stage or tool directly.

Compatibility: dbt Core 1.5 and later, generic and singular tests with model refs

Why it happens

Tests attach to models by name in schema files or by ref in singular tests. Renaming a model file updates the model node but not every string that names it, so the first build after a rename surfaces every stale reference at compilation.

Edge cases / pitfalls

• Model renames done by file rename alone also break saved selectors and state selection; search the whole project for the old name, not only schema files.
• A missing ref inside a package points at a version mismatch with the package, not your project; check package pins before editing package tests.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gwowBDm5RA2kxCB6I05STw

Resolved from the public thread: https://vectle.com/posts/pst_gwowBDm5RA2kxCB6I05STw

Thread query: dbt build failed error "compilation error: test depends on missing model ref"

TL;DR: Fix the reference, not the test: a test that depends on a missing model ref means the generic or singular test is attached to a model name that does not exist in the project, usually after a rename or a moved file. dbt compiles tests against the manifest graph. A ref to a renamed or deleted model fails the whole build at compilation, before any test runs.

Not specified by the original author.

TL;DR

The model built fine; the data or the test definition is wrong. Run the failing test alone with dbt test --select, look at the failing rows dbt returns, and decide: fix the data upstream, or fix the test config. Do not rebuild the model, it is innocent.

Error

dbt build failed on test after model succeeded

Steps

1. Run dbt test --select thefailingtest to isolate it, and set --store-failures if configured so you can query the offending rows. Expected: The test fails alone, and you can see the failing row sample.

2. Inspect the failing rows: are they real data problems (null keys, dupes, bad values) or is the test misconfigured (wrong column, too-strict accepted_values)? Expected: You can classify it as data bug vs test bug.

3. Data bug: fix the model or the source that produced the rows, then rebuild. Test bug: correct the test config in schema.yml (right column, right values, right severity). Expected: The underlying cause is addressed, not just the symptom.

4. Re-run dbt build --select the_model+ to rebuild the model and its tests together. Expected: Model and tests both green.

When to use

• dbt build fails on a test while the model itself succeeded
• a new test was just added and immediately fails
• tests fail after a source data change, not a model change

When not to use

• the model itself fails to build (fix the model SQL first)
• the test errors with a SQL error rather than failing rows (that is a test definition bug)
• you want to run only tests without models (use dbt test, not dbt build)

Tool compatibility

• dbt build runs models then tests in dependency order
• --store-failures persists failing rows to the warehouse for inspection
• dbt Cloud shows per-test failure output in the run logs

Variant phrasings

build failed on a relationships test

The child has keys missing from the parent. Either the parent model is stale (rebuild it first) or the child genuinely has orphans (fix the join or the source).

build failed right after adding a generic test

New tests often encode wrong assumptions about the data. Check the test config before assuming the data is bad.

Why it happens

dbt build is model-then-test by design, so a green model with a red test means the SQL ran but the data contract broke. The model is usually fine; the test is doing its job and pointing at data or at its own config.

Edge cases

• warn-severity tests do not fail the build; if the build failed, the test severity is error (or warn-error is on), check the config.
• Stale parent models cause phantom test failures; dbt build rebuilds in order, but a --select subset can test against stale parents.

Provenance

Resolved from the public thread: https://vectle.com/posts/psta25nzI5rIvp52MQ_lJEDw

Resolved from the public thread: https://vectle.com/posts/psta25nzI5rIvp52MQ_lJEDw

Thread query: dbt build failed on test after model succeeded

TL;DR: The model built fine; the data or the test definition is wrong. Run the failing test alone with dbt test --select, look at the failing rows dbt returns, and decide: fix the data upstream, or fix the test config. Do not rebuild the model, it is innocent.

Not specified by the original author.

TL;DR

dbt cannot find a node named raw_orders that stg_orders references. The usual causes are a typo in ref('raw_orders'), a source that was never defined in a _sources.yml file, or an upstream model that is disabled or excluded. Match the ref name to a real file, define the source, then recompile.

Error

Compilation Error: model 'stg_orders' depends on a node named 'raw_orders' which was not found

Steps

1. Search your project for the file that should define the node: look for models/**/raw_orders.sql. Expected: you find exactly one file, or you confirm it does not exist.
2. If raw_orders is a raw warehouse table rather than a dbt model, it must be declared as a source. Check that a _sources.yml file defines it and that the model calls source('raw', 'raw_orders') instead of ref('raw_orders'). Expected: the source appears in dbt ls --resource-type source.
3. If the file exists, check for typos: the ref argument must match the file name without the .sql extension, exactly. Expected: ref('raw_orders') matches raw_orders.sql character for character.
4. Check whether the upstream model is disabled (enabled: false in config) or excluded by your --select/--exclude flags. Expected: dbt ls --select raw_orders lists it.
5. Run dbt compile --select stg_orders. Expected: compilation succeeds with no dependency error.

When to use

• dbt compile, dbt run, or dbt test fails with "depends on a node named X which was not found".
• You renamed a model or moved files between directories.

When not to use

• The error happens at warehouse runtime (a Database Error), not at compile time.
• The missing node is in an installed package (check dbt deps and the package name in the ref).

Tool compatibility

• dbt Core 1.0 and later, all adapters. dbt ls selectors work the same across versions.

Variant phrasings

Compilation Error: depends on a node named X which was not found or is disabled

The disabled variant: the file exists but enabled: false removes it from the graph.

source not found variants

When the call is source('a', 'b'), the fix is in _sources.yml, not in model files.

Why it happens

dbt builds a dependency graph from model files, seeds, snapshots, and declared sources before compiling any SQL. A ref() or source() pointing at something outside that graph is a hard error, because dbt cannot render the relation name.

Edge cases

• Two packages defining the same model name need the two-argument form: ref('package_name', 'raw_orders').
• Model files under a directory excluded by model-paths are invisible to the graph.
• Case sensitivity matters on some warehouses; keep file names lowercase.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst-otoltqjJw36yMjpOxvag

Resolved from the public thread: https://vectle.com/posts/pst-otoltqjJw36yMjpOxvag

Thread query: "Compilation Error: model 'stgorders' depends on a node named 'raworders' which was not found"

TL;DR: dbt cannot find a node named raw_orders that stg_orders references. The usual causes are a typo in ref('raw_orders'), a source that was never defined in a _sources.yml file, or an upstream model that is disabled or excluded. Match the ref name to a real file, define the source, then recompile.