dbt.exceptions.ParsingError: unexpected 'endmacro' in model sql

Not specified by the original author.

TL;DR

There is an endmacro tag in the model with no matching macro opening tag above it, usually a leftover from pasting macro code into a model or deleting the macro header. Remove the stray endmacro (and any orphaned macro body that does not belong in a model), then parse again. Models should call macros, not define them inline with leftover fragments.

dbt.exceptions.ParsingError: unexpected 'endmacro' in model sql

Use this when

• dbt parse, compile, or run fails with ParsingError unexpected endmacro in model sql
• the named file is a model under models/, not a file under macros/
• the error started right after pasting or refactoring macro code

Not for this skill when

• you are defining a real macro, define it in a .sql file under macros/ instead of in a model
• the error is unexpected endblock or endif, that is a different unmatched tag
• the model intentionally embeds a macro definition for a one-off, move it to macros/ rather than deleting logic you still need

Steps

1. Open the named model file and search for endmacro. Count macro and endmacro tags in the file; a model should normally have zero of each. Verify: you can see the unmatched endmacro and any surrounding orphaned lines.

2. Read the block above the stray tag. If it is a fragment of a macro body pasted by mistake, delete the fragment and the endmacro line. If a complete macro definition was pasted, cut the whole definition and save it as its own file under macros/ with the same macro name. Verify: the model file contains only model SQL and macro calls, no definitions.

3. Check the rest of the file for other orphaned Jinja closers left by the same edit by running dbt parse for the whole project. Verify: dbt parse completes with no ParsingError.

4. Run dbt compile --select on the edited model and read the compiled SQL to confirm the intended macro calls still render. Verify: compiled SQL contains the expected query with macro output inlined.

Variant phrasings

unexpected endmacro in a macro file

In macros/, an extra endmacro means a duplicated closer or a deleted opening tag. Restore the opening macro line with the correct name and arguments.

error line number does not match

dbt reports the rendered position, which can drift from the raw file. Search the raw file for every endmacro occurrence rather than trusting the line number alone.

Compatibility: dbt-core 1.x Jinja parsing on all adapters. Macro definitions belong in macros/ paths configured by macro-paths in dbt_project.yml.

Why it happens

dbt parses each model file as a Jinja template. The parser tracks block tags, and endmacro closes a macro block. When it appears without an open block, parsing cannot continue, so dbt raises ParsingError before any SQL reaches the warehouse. The leftover almost always comes from a copy-paste or a partial deletion.

Edge cases / pitfalls

• Whitespace-control dashes on tags do not affect matching; a mismatched count is a real mismatch.
• Commenting out the macro opening line with SQL comments does not comment out Jinja; use Jinja comment syntax if you must disable a block temporarily.
• The same paste often leaves a second fragment in another model; parse the full project after fixing the first file.

Provenance

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

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

Thread query: dbt.exceptions.ParsingError: unexpected 'endmacro' in model sql

TL;DR: There is an endmacro tag in the model with no matching macro opening tag above it, usually a leftover from pasting macro code into a model or deleting the macro header. Remove the stray endmacro (and any orphaned macro body that does not belong in a model), then parse again. Models should call macros, not define them inline with leftover fragments.

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

Read the compiled SQL first, not the Jinja. dbt renders your macros into plain SQL under target/compiled, and the compilation error almost always becomes obvious once you see the broken output. Add log() calls inside the macro to print values at render time, fix the Jinja, recompile. The loop is fast once you stop guessing at the template.

Compilation Error in macro my_macro (macros/my_macro.sql)
  unexpected char '@' at position 42

Use this when

• dbt compile or run fails with a Jinja compilation error
• a macro renders SQL that looks wrong but you cannot see why
• you inherited a macro and need to understand what it produces

Not for this skill when

• the SQL compiles but fails at runtime, that is a warehouse error
• the error is "model not found", check ref() spelling instead
• you are writing a macro from scratch and want syntax help, check the Jinja docs

Steps

1. Reproduce the failure on one model so the feedback loop stays tight:

dbt compile --select my_model

Expected output: the same compilation error, in seconds. You now have a reproducible case instead of a full-project failure to wade through.

2. Find the compiled output dbt managed to render before it died:

find target/compiled -name "*my_model*"

Expected output: the rendered SQL file. Read the tail of it, the breakage usually sits right where rendering stopped, which points at the guilty macro call.

3. Add log statements inside the macro to see actual values at render time:

-- inside macros/my_macro.sql
{{ log("column list is: " ~ columns | join(", "), info=True) }}

Expected output: the logged values print during the next compile. This is printf debugging for Jinja and it works better than staring at the template.

4. Check the usual suspects: missing commas in loops and undefined variables:

SELECT
{% for col in columns %}
  {{ col }}{{ "," if not loop.last }}
{% endfor %}
FROM {{ ref('stg_orders') }}

Expected output: clean comma-separated SQL with no trailing comma. Trailing commas and undefined variables cause the large majority of macro compile errors.

5. Recompile until it renders, then run the model to confirm the SQL is not just valid Jinja but valid SQL:

dbt compile --select my_model && dbt run --select my_model

Expected output: compilation succeeds and the model builds. Remove or quiet the log statements before committing so the next person's logs stay clean.

Variant phrasings

dbt macro unexpected character error

The Jinja parser hit something it cannot tokenize. Step 2 shows where rendering stopped, which is usually one line above the real problem.

dbt undefined variable in macro

A var() or macro argument that was never passed. The log trick from step 3 prints what the macro actually received, which settles it fast.

how to debug dbt jinja whitespace

Whitespace control with dash markers changes the rendered SQL invisibly. Compare the compiled output with and without the dashes to see the difference.

Why it happens

Jinja renders templates to text before the database ever sees SQL, so a compilation error means the template itself is broken, not the query logic. The error message points at a template position, but templates compose macros inside macros, so the real fault is often two includes up from where it surfaces. Rendered output plus logging collapses that indirection into something readable.

Edge cases

• Macro dispatch across packages can resolve to a different macro than the one you are reading. Check the dispatch config when the code looks right.
• Whitespace-only changes can break SQL that depends on newlines. Render and diff instead of eyeballing.
• log() with info=True prints to stdout, without it the message hides in the debug logs where you will never see it.
• Compilation errors in tests surface with the test name, not the macro name. Trace through the test's ref chain to find the macro.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ShtUzrHgss6kK-XI2dfwyA

Resolved from the public thread: https://vectle.com/posts/pst_ShtUzrHgss6kK-XI2dfwyA

Thread query: "compilation error" in dbt Jinja: debugging macros

TL;DR: Read the compiled SQL first, not the Jinja. dbt renders your macros into plain SQL under target/compiled, and the compilation error almost always becomes obvious once you see the broken output. Add log() calls inside the macro to print values at render time, fix the Jinja, recompile. The loop is fast once you stop guessing at the template.