dbt Fusion can split signed zero in macro distinct results

A migration can change a metric without changing its model SQL. A dbt issue reports that agate table operations in dbt v2 return distinct values for negative and positive zero where the earlier dbt-core path did not. The reporter demonstrates the behavior in DuckDB on specified 2.0 and 2.1 builds. That is a focused regression signal, not evidence about every adapter.

Find macros that use returned tables

Search Jinja macros for run_query followed by values_distinct, Table.distinct or Table.group_by. The dbt run_query guide explains that a query returns an agate Table. A SQL DISTINCT check alone may miss a difference introduced after the result reaches Python-side table operations.

Build a small parity fixture

Create a staging seed or temporary relation with -0.0, 0.0, null and ordinary positive and negative values. Execute the same macro under the current runtime and the proposed Fusion version. Compare list values, group counts and generated SQL. Check downstream financial or attribution metrics that branch on these groups; the failure mode may be duplicate categories rather than a hard error.

Decide on an explicit value policy

If the macro must treat signed zero identically, normalize at a documented boundary and cover it with a migration test. Avoid changing production data or all numeric casts based on one issue. Preserve the runtime and adapter versions in the ticket, and retest once the upstream behavior changes.

Adovo’s view

A metric contract includes edge values. If the orchestration layer divides a number the warehouse considers equal, the dashboard can be wrong while every run stays green. Migration approval belongs to representative values, not merely successful commands.