Dex 1.10 fixes the case where an approved schema diff was not the change that landed

Dex 1.10 is more consequential than its compact changelog suggests. The release tightens a specific failure boundary for agent-maintained analytics projects: the gap between a reviewable proposal and the bytes that actually land in the repository.

One approved diff, a different result

The clearest example is in Dex’s reconciliation fix. A table that drifted on two axes—schema drift plus a lost unique key—could produce two edits against the same schema.yml, both pinned to the same original content hash. Applying them sequentially meant the second edit replaced the first. Dex reported success and listed the path twice, but the resulting file omitted part of the change a reviewer had approved.

Version 1.10 now stages changes through one accumulator, folds them into one edit per path and drops edits that would reproduce the existing file. It also splices changes into schema.yml rather than parsing and reprinting the whole document, preserving comments and shrinking a one-word change to a small diff. The maintainers report 3,331 passing unit tests and live checks against BigQuery, Snowflake, Databricks and ClickHouse Cloud; Redshift was explicitly not run.

Silent emptiness becomes a finding

The release also makes maintain verify flag empty, mostly NULL and fully NULL output columns. According to the merged change, a fully NULL joined column is reported at high severity, with related join metadata when available. Dex also includes the additional NULL-fraction scans in connector cost estimates and confirmed-spend accounting. That matters because a failed join can still return a syntactically valid relation; without a content check, “the query ran” can masquerade as correctness.

Maintenance without laundering freshness

A new maintain snapshot --project-only mode refreshes fingerprints from dbt and semantic files while carrying the prior warehouse snapshot forward unchanged. It preserves the original warehouse timestamp, skips adapter access and marks that no warehouse bytes were billed. In practical terms, a refactor can update project-side evidence without making stale warehouse evidence look fresh.

Semantic deletion is explicit too. A definitions payload can remove a metric or semantic model, but Dex refuses the plan when surviving project objects still reference the removed definition. The maintainers also disclose a remaining gap: deleting an entire semantic YAML file through the transform-plan path can bypass that guard.

Dex describes itself as a read-only-against-data toolkit that treats the dbt project as the source of truth and every change as a reviewable diff. Version 1.10 makes that promise more testable: reviewers need one coherent file edit, freshness provenance, and output-shape checks—not merely a successful command.