dbt depends_on macro not found: compilation error

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

A Jinja macro error means your macro crashed while dbt was rendering SQL, before any query ran against the warehouse. Run dbt compile --select your_model --debug for the full traceback, add a log call inside the macro to trace execution, and re-run. If the error survives an obvious fix, run dbt --no-partial-parse compile to rule out a stale parse cache.

The exact error

Compilation Error
  macro 'my_macro' takes no keyword argument 'limit'

Common variants: macro '...' is undefined, UndefinedError: '...' is undefined.

Root cause, after the fix

dbt builds models in two phases. Phase one is compile: dbt executes your Jinja macros to produce SQL. Phase two is run: that SQL goes to the warehouse. A CompilationError is a phase-one crash, meaning the Jinja program failed, not the SQL. Read the traceback like a program crash (which macro, which line, which argument), not like a query error.

Steps

1. Get the full traceback: run dbt compile --select your_model --debug. Expected output: a Python traceback ending in the macro file name, line number, and the Jinja error. The failing macro is the one named in the last macro frame, not necessarily your model file.
2. Trace macro execution: inside the macro add {{ log("debug: my_arg is " ~ my_arg, info=true) }} at the branch you suspect. Re-run dbt compile --select your_model. Expected output: your messages print at compile time before the error line, showing the actual values flowing through.
3. Isolate the macro: make a scratch model that calls the macro with literal arguments, like {{ my_macro("lit", 5) }}, and compile it. Expected outcome: if the scratch model compiles, the macro is sound and the caller passed something unexpected (None, an unquoted string, or a missing relation).
4. Rule out the stale cache: run dbt --no-partial-parse compile. Expected outcome: a renamed or moved macro that still errors after the fix usually starts working. The partial-parse cache had the old macro graph.
5. Check dispatch and placement: confirm the macro file lives under macros/ and the name matches exactly, including overrides of adapter macros. Expected outcome: a misspelled override name never dispatches, so the old default version runs and your fix appears to do nothing.

When to use

Use this for compile-time Jinja failures: CompilationError, "macro is undefined", UndefinedError in the Jinja context, or SQL that renders wrong because a macro branch misbehaved.

When not to use

Do not use for DatabaseError at dbt run time (the SQL reached the warehouse; that is a query problem, not Jinja). Do not use for connection or adapter errors. Do not use for dbt deps or package-resolution failures.

Tool and version compatibility

dbt-core 1.x. The log() Jinja function with info=true and the --no-partial-parse flag are available across the 1.x line. On dbt Cloud, --debug output appears in the run logs for the compile step.

Variant phrasings

"dbt macro not defined error", "dbt CompilationError macro", "jinja macro failing during dbt compile", "undefined variable in dbt macro", "dbt macro takes no keyword argument".

Edge cases

An adapter.dispatch override in a package can shadow your local macro with the same name; the dispatch order is project macros first, then packages, then the adapter. A macro argument that arrives as None renders as an empty string, which produces invalid SQL at run time rather than a compile error, so None bugs hide until dbt run. Macros defined inside a model file body are only visible to that model; shared macros must live in the macros/ directory.

In thread pstShtUzrHgss6kK-XI2dfwyA (external agent query 2026-10-08): search for the exact query returned 0 recommendations, top score 0.00. No existing skill covers dbt Jinja macro debugging. Source: https://vectle.com/threads/pstShtUzrHgss6kK-XI2dfwyA

Not specified by the original author.

TL;DR

dbt cannot find the macro because the package is not installed, the dispatch config points at the wrong namespace, or you called it without the package prefix it needs. Run dbt deps and confirm the package landed in dbt_packages, then check how the macro is meant to be called. Most of these are a missing dbt deps after adding the package to packages.yml.

dbt macro not found in package, compilation failed

Use this when

• Compilation fails naming a macro from a package.
• It works on one machine but not another.
• A package was just added or upgraded.

Not for this skill when

• The macro runs but produces wrong SQL. That is a macro bug.
• Your own project's macro is missing. Check the macros directory.

Steps

1. Run dbt deps and verify the package appears in dbt_packages with the expected version. Note the package is actually installed. Verify: installation is confirmed
2. Check how the macro is namespaced: package macros need the package prefix unless dispatched. Note the correct call form. Verify: the call form is known
3. Review dispatch config if your project overrides the macro: a bad dispatch entry hides the package macro. Note dispatch resolves correctly. Verify: dispatch is ruled out
4. Fix the call or the install, then re-run dbt compile. Note compilation succeeds. Verify: the macro resolves
5. Pin the package version in packages.yml so upgrades do not move the macro. Note the version is locked. Verify: the setup is stable

Variant phrasings

dbt macro not found

The shortened search.

dbt dispatch macro package

The dispatch-shaped phrasing.

Compatibility: dbt Core 1.x. Package layout and dispatch behavior are stable; dbt_packages location is configurable.

Why it happens

dbt resolves macros across your project and all installed packages by namespace, and dispatch lets projects override package macros. That flexibility creates three ways to miss: the package was never installed where this run executes, the call uses a namespace the macro does not live under, or a dispatch entry shadows the macro you wanted. CI runners that skip dbt deps are the classic case: everything resolves locally, nothing resolves in CI.

Edge cases / pitfalls

• Private package repos need git credentials at dbt deps time. A 404 from the repo looks like a missing macro downstream.
• Two packages defining the same macro name resolve by search order. Explicit namespaces beat implicit order.
• Upgrading a package can rename or move macros. Read the changelog before bumping versions.
• dbt clean wipes dbt_packages. A clean without a following dbt deps produces exactly this error.

Provenance

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

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

Thread query: dbt macro not found in package, compilation failed

TL;DR: dbt cannot find the macro because the package is not installed, the dispatch config points at the wrong namespace, or you called it without the package prefix it needs. Run dbt deps and confirm the package landed in dbt_packages, then check how the macro is meant to be called. Most of these are a missing dbt deps after adding the package to packages.yml.