Summary
When running uvx dbt-autofix against a dbt_project.yml that uses +pre_hook: at a model-group level, the tool moves the key into +meta: rather than renaming it to the canonical +pre-hook: hyphen form that dbt-core + Fusion expect. The result silently disables execution of the hook — +meta is free-form metadata with no runtime effect.
Version: dbt-autofix==0.20.3 (reproduced on 0.19.x also).
Reproduction
Minimal dbt_project.yml input:
models:
myproject:
marts:
+materialized: table
+pre_hook: "SET LOCAL statement_timeout = '900s'"Run: uvx dbt-autofix
Actual output:
models:
myproject:
marts:
+materialized: table
+meta:
pre_hook: "SET LOCAL statement_timeout = '900s'"Expected output (canonical hyphen form per dbt 1.10+ schema, Fusion-compatible):
models:
myproject:
marts:
+materialized: table
+pre-hook: "SET LOCAL statement_timeout = '900s'"Impact
+meta is dbt's free-form metadata bag with no execution semantics. Whatever SQL was previously wrapped in pre_hook now silently stops firing on every run, which is especially dangerous when the hook was load-bearing (e.g., a statement-level timeout for large-table materializations). Users discover the regression only when a downstream mart starts timing out in production or an audit catches the behavior gap.
Context
We hit this migrating a dbt-core 1.11.2 project to the 1.10-compatible schema to prepare for Fusion. Workaround we documented in our repo's memory: revert the dbt_project.yml change after autofix, then rename +pre_hook → +pre-hook manually. All other autofix transformations (arguments: nesting for generic tests, source freshness moves, etc.) applied cleanly.
Suggested fix
The PropertyMovedToConfigDeprecation pass appears to be catching pre_hook as a plain property and routing it under +meta instead of recognizing it as a hook key that needs the hyphen rename via ConfigPreHookDeprecation (or equivalent). The hook-specific rename should run before (or exclude from) the generic move-to-meta pass.
Happy to open a PR if a test fixture + the pass ordering fix is the right shape.
Summary
When running
uvx dbt-autofixagainst adbt_project.ymlthat uses+pre_hook:at a model-group level, the tool moves the key into+meta:rather than renaming it to the canonical+pre-hook:hyphen form that dbt-core + Fusion expect. The result silently disables execution of the hook —+metais free-form metadata with no runtime effect.Version:
dbt-autofix==0.20.3(reproduced on 0.19.x also).Reproduction
Minimal
dbt_project.ymlinput:Run:
uvx dbt-autofixActual output:
Expected output (canonical hyphen form per dbt 1.10+ schema, Fusion-compatible):
Impact
+metais dbt's free-form metadata bag with no execution semantics. Whatever SQL was previously wrapped inpre_hooknow silently stops firing on every run, which is especially dangerous when the hook was load-bearing (e.g., a statement-level timeout for large-table materializations). Users discover the regression only when a downstream mart starts timing out in production or an audit catches the behavior gap.Context
We hit this migrating a dbt-core 1.11.2 project to the 1.10-compatible schema to prepare for Fusion. Workaround we documented in our repo's memory: revert the
dbt_project.ymlchange after autofix, then rename+pre_hook→+pre-hookmanually. All other autofix transformations (arguments: nesting for generic tests, source freshness moves, etc.) applied cleanly.Suggested fix
The
PropertyMovedToConfigDeprecationpass appears to be catchingpre_hookas a plain property and routing it under+metainstead of recognizing it as a hook key that needs the hyphen rename viaConfigPreHookDeprecation(or equivalent). The hook-specific rename should run before (or exclude from) the genericmove-to-metapass.Happy to open a PR if a test fixture + the pass ordering fix is the right shape.