dbt-core v1.12.4 - Fusion Manifest And OTEL IDs

dbt-core v1.12.4 shipped on 8 September 2026. After a Fusion generated manifest is loaded, the four built in generic tests are parsed again so they are not evicted and left undefined when tests compile. The tag also adds otel_trace_id() and otel_span_id() Jinja functions so query comments can carry OpenTelemetry IDs.

The full release notes and downloads are on the GitHub release page.

When Core loads a Fusion generated manifest, the four built in generic tests go missing. test_not_null, test_unique, test_accepted_values, and test_relationships are evicted and stay undefined when tests compile.

That is a hole in the macro namespace. A dbt test compile after a Fusion parse then fails on names every project expects to exist. The failure looks like a missing project file. It is not.

Issue 15914 tracks it. v1.12.4 parses those four tests again after the Fusion manifest is in memory. The adapter macros used for compilation come back.

The file on disk was wrong in the same way. Fusion’s bundled macros were written to target/manifest.json. Later steps that read the artifact would see Fusion’s copies, not the adapter macros Core actually compiled against. The patch writes target/manifest.json from the corrected in memory manifest.

If CI compiles tests after a Fusion parse, start here. Compare the macros in target/manifest.json with the adapter the run used. Before this tag, those two views could disagree. The notes do not add a flag to skip the reload. It is part of loading that manifest.

Warehouse query history is hard to join to a trace if the comment has no trace ID. otel_trace_id() and otel_span_id() are Jinja functions that return the current OpenTelemetry IDs. Put them in a query comment or in model SQL and the warehouse row can be joined to the APM span.

The notes frame this as correlation between query comments, model SQL, and OpenTelemetry IDs. They do not ship a new comment template. Nothing changes until a project calls the functions.

No new CLI flag is named. No new config key is named. This is additive Jinja. Models that never call the helpers compile the same SQL as before.

If you already inject a run ID into comments, these two calls are the missing trace and span fields. If you do not use OpenTelemetry in the dbt process, the notes do not say what the functions return. Do not assume a dummy ID until you test it.

Fusion parser output used to pass straight to stdout and stderr. v1.12.4 captures the subprocess and sends each line through the dbt-core event system. When a line has json-compat severity, that value sets the event level. Issue 15672 tracks the change.

JSON log pipelines then see Fusion parser lines as events. Parser dumps stop leaking onto the process streams. That is the operator visible part. If a line has no severity, the notes do not say which level is used.

A resolved package install path is also checked against packages-install-path. The install must stay inside that directory. This site already covered the same class of check on dbt-core v1.11.15. The 1.12 line now has it too.

JSON schemas are synced from dbt-fusion. The notes list this as internal work. It is a schema copy. Calling dbt stays the same. Fusion and Core artifacts are supposed to agree on field names after this tag.

No breaking changes or migration steps are listed. Install v1.12.4 if you load Fusion manifests or stamp OpenTelemetry IDs into query comments. The parser event change is safe for everyone else on the 1.12 line.