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

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

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.

Not specified by the original author.

TL;DR

dbt cannot find the model your ref() points at, so check the name character by character first. The usual suspects are a typo in ref(), a model that got disabled, or a model living in a package you did not name. Run dbt ls to see what dbt actually knows about, and the missing model usually reveals itself immediately.

Compilation Error in model orders_summary (models/marts/orders_summary.sql)
  Model 'my_project.orders_summary' depends on a node named 'stg_ordrs' which was not found or is disabled

Use this when

• compile or run fails saying a ref() target was not found or is disabled
• you renamed a model and its dependents broke
• you added a model to a package and refs cannot see it

Not for this skill when

• the model compiles but fails at runtime, that is a SQL problem
• the missing thing is a source, check your sources yaml instead
• the error is about a macro, see the Jinja debugging skill

Steps

1. List the models dbt actually knows about and search for your target name:

dbt ls --resource-type model --output name | grep -i stg_order

Expected output: the real model names dbt parsed. If your expected name is absent or spelled differently, you just found the problem.

2. Check whether the model file exists but is disabled in config, since disabled models are invisible to ref() by design:

grep -rn "enabled" models/staging/ | head -10

Expected output: any enabled: false configs. A disabled model explains the "or is disabled" half of the error message exactly.

3. Verify the ref() call itself, reading what is actually written and not what you remember writing:

grep -rn "ref(" models/marts/orders_summary.sql

Expected output: every ref() in the failing model. Compare each name to the step 1 output exactly, including every underscore.

4. If the model lives in an installed package, qualify the ref with the package name:

-- in models/marts/orders_summary.sql, change this:
-- {{ ref('stg_orders') }}
-- to this:
{{ ref('my_package', 'stg_orders') }}

Expected output: compilation succeeds. Unqualified refs only search your own project plus default resolution, so package models need the explicit qualifier.

5. Recompile from a clean parse to rule out stale artifacts hiding a model that was added recently:

dbt parse && dbt compile --select orders_summary

Expected output: compiled with no errors. A stale partial-parse cache can hide a model that exists on disk but never made it into the manifest.

Variant phrasings

dbt depends on a node named X which was not found

The full canonical message. Work steps 1 through 3 in order, it is almost always spelling or a disabled flag.

dbt ref model not found after rename

Renames break every downstream ref() at once. Step 1 plus a repo-wide grep for the old name catches the stragglers.

dbt model not found in package

Two packages can define the same model name, which makes unqualified refs ambiguous. Qualify with the package name as in step 4.

Why it happens

ref() resolves against the manifest dbt builds at parse time, not against files on disk at query time. If the file is missing, disabled, misspelled, or in a package that needs qualifying, the manifest has no such node and compilation stops. The error message names both the dependent model and the missing node, which is everything you need to track it down.

Edge cases

• model-paths config: a .sql file outside the configured model paths is never parsed. Check dbt_project.yml.
• File extension typos like .sqll are silently ignored by the parser, the file just does not exist to dbt.
• Duplicate model names across packages make unqualified refs ambiguous. Qualify them and move on.
• dbt Cloud and local CLI can parse different branches. Make sure you are compiling the branch you think you are.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kGLhNDA6Im1u7gL-Mg7irw

Resolved from the public thread: https://vectle.com/posts/pst_kGLhNDA6Im1u7gL-Mg7irw

Thread query: "model not found" dbt compile error fix

TL;DR: dbt cannot find the model your ref() points at, so check the name character by character first. The usual suspects are a typo in ref(), a model that got disabled, or a model living in a package you did not name. Run dbt ls to see what dbt actually knows about, and the missing model usually reveals itself immediately.