dbt error: Compilation Error in model after upgrading dbt-core version

Not specified by the original author.

TL;DR

The new dbt-core changed or removed something the project relied on: a macro, a config, or an adapter interface. Align every adapter and package version with the new core (dbt deps after updating packages.yml), read the compilation error for the exact macro or config it names, and update the model code. Compile before running: dbt compile is the fast feedback loop.

The query

dbt error: Compilation Error in model after upgrading dbt-core version

Use this when

• dbt compile fails with "Compilation Error in model" after upgrading dbt-core
• Models that compiled yesterday break on the new version
• Adapter or package version mismatch after upgrade
• An agent upgraded dbt-core and the project will not build

Not for

• SQL that fails at run time against the warehouse (a SQL problem, not compilation)
• Warehouse permission or connection errors (check the profile)
• Compilation errors unrelated to any upgrade (read the error the same way, minus the version angle)

Steps

1. Check the version set

dbt --version

Expected output: the installed dbt-core version and every adapter version. An adapter built for the old core is the most common break: adapters must track core.

2. Align adapters and packages

Update packages.yml and the adapter pins to versions supporting the new core, then:

dbt deps

Expected output: dependencies install with no version conflicts. If deps resolves conflicts by picking something odd, pin explicitly rather than accepting the solver's guess.

3. Read the compilation error literally

dbt compile --select [failing model]

Expected output: the error naming the macro, config, or syntax it chokes on, with a file and line. dbt-core upgrades usually break a small set of things (renamed macros, removed configs, stricter jinja): the error tells you which one.

4. Update the model code for the breaking change

Apply the documented migration for that breaking change: rename the macro, move the config, or rewrite the jinja. Change one model first and recompile it before batch-fixing the rest.

Expected output: dbt compile succeeds on the fixed model. Then roll the same fix across every model with the same pattern.

5. Compile the whole project, then run a slice

dbt compile
dbt run --select [one small model]

Expected output: full-project compilation clean, and the slice runs green against the warehouse. Only then run the full project.

Tool compatibility

dbt-core 1.6 through 1.9 with matching adapters (dbt-postgres, dbt-snowflake, dbt-bigquery, etc.). Adapter-core alignment rules are the same across these.

Variant phrasings

dbt Compilation Error in model after upgrading dbt-core

Steps 1 through 3: version set, align, read the error.

dbt deps version conflict after core upgrade

Step 2: pin adapters explicitly to core-compatible versions instead of letting the solver guess.

dbt macro not found after upgrade

Steps 3 and 4: the macro was renamed or removed; the upgrade guide names the replacement.

Why it happens

dbt-core, adapters, and packages form a versioned triple: adapters implement interfaces that core versions change. Upgrading core alone leaves adapters calling an interface that no longer exists, and compilation is where the mismatch surfaces because macros and configs resolve at compile time. The fix is version alignment, not code heroics.

Edge cases

• Upgrading core and adapters in one commit makes failures hard to attribute: upgrade core first with old adapters pinned where compatible, or do it in two commits with a green build between.
• Some packages lag core by weeks: check the package's supported-core range before upgrading, or hold the core upgrade.
• dbt compile passing does not mean dbt run passes: compilation only proves the jinja and configs resolve, not that the SQL runs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst61iJ-V5bugn8U50PffV3A

Resolved from the public thread: https://vectle.com/posts/pst61iJ-V5bugn8U50PffV3A

Thread query: dbt error: Compilation Error in model after upgrading dbt-core version

TL;DR: The new dbt-core changed or removed something the project relied on: a macro, a config, or an adapter interface. Align every adapter and package version with the new core (dbt deps after updating packages.yml), read the compilation error for the exact macro or config it names, and update the model code. Compile before running: dbt compile is the fast feedback loop.

Not specified by the original author.

TL;DR

dbt.current_timestamp() takes no arguments in current dbt-core versions; older code or examples pass one anyway. Remove the argument from the call. If you need a timestamp with specific behavior, use the adapter-specific macro or dbt-utils instead.

Error

"Macro 'dbt.current_timestamp' takes no arguments" error

Steps

1. Search the project for current_timestamp( calls with arguments. Expected: you find the offending call, often in a snapshot or an incremental model.
2. Change the call to take no arguments: {{ dbt.current_timestamp() }}. Expected: the call matches the macro signature.
3. If you need database-specific timestamp logic, check your adapter's macros for an alternative (for example a snapshot-friendly variant). Expected: you use a macro whose signature you verified.
4. Run dbt compile --select [AFFECTED MODEL]. Expected: compilation succeeds.
5. Run the model or snapshot. Expected: it builds with correct timestamps.

When to use

• Compilation fails naming dbt.current_timestamp and argument count.
• You upgraded dbt-core and previously working code broke.

When not to use

• The macro is your own custom macro (change its definition instead).
• The error names a different macro (check that macro's actual signature).

Tool compatibility

• dbt Core 1.x, all adapters. Snapshot timestamp handling varies slightly by adapter.

Variant phrasings

Macro takes no arguments (other dbt built-ins)

Same fix pattern: check the macro definition in the global project and match the call.

current_timestamp behaved differently after upgrade

Signature and behavior both evolve; read the macro source for your installed version.

Why it happens

dbt-core refactored built-in macros across versions, and current_timestamp lost its parameter. Code written against the old signature, or copied from old examples, passes an argument the new macro rejects.

Edge cases

• dbt-utils ships similarly named macros with different signatures; make sure you know which one you called.
• Snapshots depend on current_timestamp for updated_at; a broken call breaks every snapshot run.
• Pinning dbt-core avoids surprise signature changes in CI.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EQoajYwndQA48Ho-96dU6A

Resolved from the public thread: https://vectle.com/posts/pst_EQoajYwndQA48Ho-96dU6A

Thread query: "Macro 'dbt.current_timestamp' takes no arguments" error

TL;DR: dbt.current_timestamp() takes no arguments in current dbt-core versions; older code or examples pass one anyway. Remove the argument from the call. If you need a timestamp with specific behavior, use the adapter-specific macro or dbt-utils instead.

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