dbt format panics on a conditional Jinja loop

A formatting gate can fail before a warehouse query runs. A dbt 2.0.8 report reproduces a Block stack is empty panic when a whitespace-trimmed Jinja for loop contains an if that is true for only some iterations. The report says a project-wide dbt format can rewrite earlier files and then stop at the affected model. This is a version-specific report, not a claim about every Jinja loop.

Isolate the exact template

Run dbt format --check on the smallest failing file and record dbt and formatter versions. Compare the result with dbt lint; the issue reports lint did not panic on the same file. Check whether {%- and -%} trimming, loop length, and conditional branch match the reproducer before attributing a new failure to this issue. Keep the original file in version control so a partial format run is reversible.

Protect the release pipeline

Use check mode in CI, and run any rewriting command only in a clean working tree. If formatting fails, stop the release gate, retain the error and file path, and avoid committing partial rewrites. A temporary rewrite of whitespace controls may unblock a specific model, but it should be reviewed for generated SQL equivalence. Do not claim a fix without testing both formatted output and dbt compilation.

Ask for a durable outcome

The useful delivery artifact is a minimal reproducer plus a locked tool version and a regression test for the template shape. Track the upstream issue and remove any local exception only after a tested release resolves it.

Adovo’s view

Formatting is supposed to reduce review risk. When it can mutate files before failing, the gate needs isolation and rollback. A clean diff matters more than a green formatter badge.