How should projects handle Fusion-specific warn_error_options while pre-commit hooks still run on dbt-core (Python)?

[FrankTub]

Hi maintainers — this is more of a question about the recommended migration pattern than a bug report, hence Q&A rather than an issue. Happy to move it if there's a better venue.

Situation

We're mid-way through migrating a dbt project to the dbt Fusion engine. To prepare, we've added Fusion-specific names to warn_error_options.silence in dbt_project.yml:

flags:
  warn_error_options:
    silence:
      - ColumnTypeMismatch      # Fusion error code dbt1058
      - ValidateMacroArgs       # Fusion error code dbt1506

Both names are defined in the Fusion Rust codebase (crates/dbt-error/src/codes.rs) but not in the Python dbt-core event catalog (core/dbt/events/types.py), in any released version (1.11.11, 1.11.12, or 1.12.0rc2). This is expected — the two engines have independent error taxonomies.

The problem is that our pre-commit setup still runs the Python engine, and WarnErrorOptionsV2._validate_items in dbt_common.helper_types rejects any name that isn't in ALL_EVENT_NAMES:

dbt_common.dataclass_schema.ValidationError: ColumnTypeMismatch is not a valid dbt error name.

The failure happens at flag-parsing time in dbt/cli/requires.py, so every dbt command in the Python env fails — dbt clean, dbt deps, dbt compile, dbt test, etc. Our .pre-commit-config.yaml pins dbt-core==1.11.11 for the dbt-checkpoint hooks (dbt-clean, dbt-deps, dbt-compile, dbt-run, dbt-test, dbt-docs-generate), plus sqlfluff-templater-dbt and dbt-osmosis all import Python dbt-core — none of these hook ecosystems have Fusion-native releases yet that we're aware of.

What we found in existing threads

• PR Fusion warn error options tolerance #15212 ("Fusion warn error options tolerance") does exactly what we'd want — it accepts Fusion-only names in dbt-core, emits a note instead of erroring, and keeps real typo detection. It targeted 1.12.latest. It was closed by its author on 2026-06-30 without maintainer discussion visible on the PR.
• Issue [v2 Bug] dbt Fusion does not support ConstraintNotEnforced or ConstraintNotSupported #15517 is the mirror problem on the Fusion side: Fusion-known names like ConstraintNotEnforced / ConstraintNotSupported can't be silenced under Fusion. Still open, labelled triage / bug.
• dbt-labs/dbt-autofix doesn't currently rewrite this configuration (no mention of ColumnTypeMismatch / ValidateMacroArgs in the repo).

Questions

1. Is there an officially recommended pattern for holding both engines' warn_error_options in a single dbt_project.yml during migration? Options we've considered:
   • Removing the Fusion-only names from dbt_project.yml and passing them via --warn-error-options '{"silence": [...]}' only in the Fusion CLI invocations
   • Splitting the config with Jinja based on some engine indicator
   • Keeping two dbt_project.yml files (undesirable)
2. Is PR Fusion warn error options tolerance #15212 (or an equivalent) on the roadmap for a 1.12.x release, or has the direction shifted? If it's not planned, we can adopt a workaround with confidence.

Not blocking — we can just remove the two entries until Fusion is our runtime everywhere — but wanted to check whether we're missing a supported pattern before doing so. Thanks!

Environment

• dbt-core 1.11.11, dbt-snowflake 1.11.6 (Python, via pre-commit)
• dbt Fusion 2.0.0-preview.* (target engine)
• macOS / Linux CI

[RenSolvyn]

Not a maintainer, so the roadmap half of your question 2 is theirs to answer, but the behavioral half turned out to be empirically checkable, and the result changes the picture: the tolerance you want already exists in 1.12.0rc2. I reproduced your setup and ran the candidate patterns against released dbt-core rather than reasoning about them; matrix below.

Setup: a minimal project with your exact block, flags.warn_error_options.silence: [ColumnTypeMismatch, ValidateMacroArgs], exercised via dbt deps.

Version and mechanism	Result
1.11.11, names in yml, nothing else	ValidationError from WarnErrorOptionsV2, your exact message, every command
1.11.11, DBT_WARN_ERROR_OPTIONS='{"error": [], "warn": [], "silence": ["Deprecations"]}' env var, yml untouched	PASS
1.11.11, dbt --warn-error-options '{"silence": ["Deprecations"]}' deps, yml untouched	PASS
1.11.11, silence: ["{{ env_var('X', 'Deprecations') }}"] in yml	ValidationError
1.12.0rc2, names in yml, nothing else	PASS, with a note per name that it is not being used because it is specific to the dbt Fusion engine

Three findings worth more than the pass/fail column:

1. The 1.12.0rc2 behavior is exactly what PR Fusion warn error options tolerance #15212 described: Fusion-only names are accepted, an informational note is emitted, and real typos still fail (a made-up name still raises). Your check of core/dbt/events/types.py was the wrong test for this, since the tolerance is not name registration in the event catalog but recognition in the validator, which is why the names are absent there while the config passes. I also isolated where it lives: 1.11.11 paired with the same dbt-common 1.38.0 that rc2 pulls still rejects, so the change is on the dbt-core 1.12 side, not something you can get on 1.11.x via a dbt-common bump.
2. On 1.11.x, flag precedence replaces rather than merges: with the env var or CLI flag present, the yml's warn_error_options is never evaluated at all, which is what makes the override safe with the Fusion names left in the file. The corollary is that any silences you still want under the Python engine must be repeated inside the override value.
3. Your Jinja option cannot work on the Python side, and the failure mode is instructive: the error message contains the raw unrendered template ({{ env_var('X', 'Deprecations') }} is not a valid dbt error name), meaning dbt-core's project renderer does not render Jinja inside the flags: block at all. Engine-switching there is off the table regardless of which engine's names you default to.

So the pattern I would run with, in order:

• If your hook ecosystem tolerates it, bump the pre-commit pin (the dbt-core entry in the dbt-checkpoint hooks' additional_dependencies, plus wherever sqlfluff-templater-dbt and dbt-osmosis get their dbt-core) to 1.12.0rc2 now or 1.12.x at GA. Your dbt_project.yml then needs no changes and no override machinery; the two Fusion names ride along with a note. Since rc behavior can change before GA, one confirming run after any bump is cheap: dbt deps in the project and grep for the note.
• Until you can move the pin, keep the yml speaking Fusion and export DBT_WARN_ERROR_OPTIONS='{"error": [], "warn": [], "silence": [<core-side silences you still want>]}' in developer shells and as an env entry on the CI step that runs pre-commit. pre-commit inherits the process environment, so one export covers all six dbt-checkpoint hooks with no per-hook config. I verified this through the dbt CLI, which is what dbt-checkpoint shells out to; sqlfluff's programmatic dbtRunner path resolves flags through the same requires.py machinery so it should behave identically, but that is the one invocation style I did not separately execute, worth a single confirming run on your side.

Your fallback of deleting the two entries until Fusion is the only runtime remains fine too; it is just no longer necessary, since on 1.12.0rc2 the file you already have passes as-is.