bug(datasets): Jinja-templated SQL triggers invalid syntax error on dataset save

[goldjee]

Bug description

When saving a virtual dataset with Jinja macros (e.g., {% if from_dttm %}) in its SQL query through the Dataset Editor modal, an "Invalid SQL" validation error is raised, even though the Jinja syntax is perfectly valid and the query executes correctly at runtime.

Expected behavior

The dataset should save without errors. Jinja templates that are syntactically valid should not be rejected by save-time SQL validation.

Screenshots/recordings

No response

Superset version

6.0.0

Python version

3.11

Node version

18 or greater

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

This is a known issue that has been addressed through several PRs. The root cause is that sqlglot attempts to parse unrendered Jinja templates as literal SQL, treating {% if %} syntax as invalid SQL rather than template syntax.

Recent fixes:

• PR #36422 (merged Jan 2026) - SQL validation now renders Jinja templates with provided template_params before validation
• PR #34802 - Fixed template parameters not being threaded through the SQL processing pipeline

If you're still seeing this on 6.0.0:

1. Enable template processing - Ensure ENABLE_TEMPLATE_PROCESSING: True is set in your feature flags

2. Use defensive conditionals for filter values that may be empty at save time:

   {% set filter_vals = filter_values('column_name') %}
   {% if filter_vals %}
     AND column_name IN {{ filter_vals | where_in }}
   {% endif %}

3. Check template_params - Ensure template_params are being passed with your dataset save request

The core issue is that during dataset save, validation attempts to render templates without access to runtime values (like from_dttm, filter values) that are only available during query execution. The fixes ensure templates are properly rendered with available context before sqlglot parsing.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[goldjee]

@dosu Both PRs you've linked mention SQL Lab. This bug is present in dataset editor modal window in 6.0.0. While a query contains Jinja templates, Save button triggers an error, although in fact the dataset is saved.

[dosubot]

You're right, my apologies for the confusion. The Dataset Editor modal has a different issue than what those SQL Lab PRs addressed.

The behavior you're seeing (error shown but dataset actually saves) is caused by a two-stage save process in the Dataset PUT endpoint:

1. Stage 1: UpdateDatasetCommand saves the dataset successfully ✅
2. Stage 2: RefreshDatasetCommand runs immediately after to sync column metadata by executing the SQL with LIMIT 1

The error occurs in Stage 2 because get_virtual_table_metadata() processes Jinja templates without runtime context — functions like filter_values() return empty lists, generating invalid SQL like WHERE col IN ().

This is a known issue tracked in #33591 and #25839. The core problem is that Dataset Editor validates at save time without runtime context, whereas SQL Lab validates at execution time with full context.

This appears to be a separate bug from the SQL Lab fixes and may warrant its own fix specifically for the Dataset Editor's metadata refresh flow.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}