Skip to main content

Template Rendering Errors - Jinja and Parse Issues

When a Node's Jinja or configuration templates are invalid, Coalesce can fail during Deploy or Preview with a template rendering error. This page describes frequent parse-style problems, what they usually mean, and where to look first. For deployment workflow and isolation tips, see Troubleshooting Template Rendering Errors. For warehouse date functions in SQL, use Using Dynamic Dates, which covers warehouse functions rather than Jinja parse errors.

How Template Errors Appear​

Template rendering runs before generated SQL is sent to the warehouse. Mistakes in Jinja syntax, braces that are doubled or unclosed, invalid filters, bad JSON produced by templates, incorrect macro calls, or misuse of Helper Tokens often show up in this phase. The error text might reference a line or character position in generated SQL or in template output, which helps you locate the template that produced it.

Where Templates Run in the Node Editor​

Use this list to decide which part of the Node to open first when you are tracing an error:

  • Create - SQL and templates used when the object is created or recreated.
  • Run - SQL and templates used when the Node runs its load or transform logic.
  • Pre-SQL - SQL run before the main operation; Jinja is evaluated here when the Node is built or run, depending on your Node type and Package.
  • Post-SQL - SQL run after the main operation, with the same templating behavior as Pre-SQL for your type.

If the message looks like warehouse SQL, for example a SELECT the Node generates, the faulting template is usually in Create or Run. If it references statements you only defined in Pre-SQL or Post-SQL, open those editors on the same Node first.

When the Error Points to a Character Position​

Some messages include a position in a line of generated SQL or rendered output. Treat that output as the result of your templates, not necessarily the file where you typed the mistake. Work backward from the shown fragment to the Node field that could emit that text: Create, Run, Pre-SQL, Post-SQL, column Transform, or a configuration field driven by Jinja. Undo recent edits in that area, simplify the expression, and redeploy or preview again.

Common Causes​

These issues often trigger a template rendering error before SQL reaches the warehouse:

  • Unclosed or doubled {{ and }} - The renderer expects balanced expression delimiters. Extra } characters or missing }} often produce parse failures.
  • Invalid filter or expression syntax - Typos in filter names, wrong pipe syntax, or broken expressions after editing filters or nested {{ }} can yield messages such as expected name or number from the template engine.
  • {% set %} and control blocks - Missing {% endif %}, {% endfor %}, or invalid assignments inside {% %} break parsing before SQL is built.
  • Invalid JSON from templates - Configuration fields that must stay valid JSON can break when Jinja emits a trailing comma, an unquoted bare word, or an empty value. See Unexpected RIGHT_BRACE for JSON brace issues tied to templates.
  • Macro misuse - Wrong argument counts, quoting, or calling a macro that itself emits invalid SQL or JSON.
  • Helper tokens inside strings or JSON - Helper Tokens look like {{SRC}} but follow Coalesce replacement rules. Nesting them inside strings or JSON without the quoting pattern your macro expects can break Jinja or JSON. See Macros and Tokens for the recommended {{ my_macro('{{SRC}}') }} style.

Possible Solutions​

Try these steps before you escalate:

  • Narrow the failing surface - Deploy or preview a smaller change set, or 1 Node, so the error stays tied to 1 template. The workflow in Troubleshooting Template Rendering Errors matches this step.
  • Validate Jinja structure - Compare your expressions with Jinja Syntax and the official Jinja Template Documentation for full grammar. Fix unclosed blocks, filters, and {% %} pairs.
  • Separate template errors from warehouse errors - If the message is a warehouse SQL compilation error and there is no template rendering prefix, the template phase already succeeded. Fix object names, permissions, or warehouse SQL in the rendered statement instead of chasing Jinja delimiters.
  • Check JSON-like configuration - For fields on a Node or in a custom Node Type that store JSON, preview the rendered value mentally: strings in double quotes, no trailing commas, braces balanced. Use Unexpected RIGHT_BRACE when the error mentions JSON state or stray }.
  • Confirm parameters and Packages - Missing Workspace parameters or outdated Packages can surface as template failures when templates expect values. Align with the parameter checks in Troubleshooting Template Rendering Errors.
  • Review helper and ref patterns - Use Helper Tokens for column context in transforms and Ref Functions for fully qualified object names and DAG-safe references. Do not substitute one for the other when the docs call for a specific pattern.
Template phase versus SQL compilation and error messages

Template rendering expands Jinja and Coalesce-specific tokens into SQL and configuration text. The warehouse then parses that SQL. A clean template render followed by a warehouse error is a SQL compilation issue, not a Jinja parse problem.

Exact error strings can change with renderer or Package versions. Focus on stable patterns such as unclosed {{, invalid JSON from a template, or unexpected } in JSON, and use the official Jinja Template Documentation when you need authoritative syntax.

What's Next?​