Broken Model from a Source Column Rename

The scenario

A Fivetran-synced retail source column was renamed upstream overnight. The dbt run fails referencing the old column name.

Find what changed, find every file that referenced the old name (SQL, source definitions, YAML tests), edit the source-side identifier while preserving the downstream alias, recompile, re-run.

Prompts, in order

The prompts use placeholders [OLD_COLUMN], [NEW_COLUMN], and [BROKEN_MODEL]. Substitute the values for your path. The placeholder table is below.

1. Pre-step: Reproduce the failure

   The lab environment ships with the rename already applied to the source table. Run dbt first to surface the real error, then proceed in dbt Wizard.

   Run in your terminal, not in dbt Wizard. From the project root:

   dbt run --select [BROKEN_MODEL]+

   You will see a compile or runtime error referencing [OLD_COLUMN]. Capture the exact error text; Step 1 uses it.
2. Explain the failure

   dbt Wizard reads the most recent run results and identifies the model name, failing column, and upstream source.

   My dbt run just failed. Read the most recent run results and tell me which model failed, what the error was, and which upstream source or column the error references.

   Then ask for the current schema.

   Describe the current schema of the upstream source table that [BROKEN_MODEL] reads from. List every column that exists today.

   Exercises: status, dbt_show against run-results, error parsing
3. Compare model code against current source schema

   dbt Wizard pulls the live column list from Snowflake and compares it against what the model references. Identifies the rename concretely.

   Show me every model, source definition, and test in this project that references the column [OLD_COLUMN]. I need a complete blast-radius list before I change anything.

   Confirm both column names explicitly: [OLD_COLUMN] renamed to [NEW_COLUMN]. Inferring the new name from context is the most common source of incorrect fixes here.
   Exercises: describe, warehouse
4. Blast-radius check

   dbt Wizard returns every file that references the old name: staging SQL, intermediate SQL, mart SQL, column tests in _staging__models.yml, and other YAML descriptions.

   Update [BROKEN_MODEL] and every other file you just listed to use [NEW_COLUMN] instead of [OLD_COLUMN]. Keep the downstream column alias the same so consumers of these models don't break - only the source-side reference should change.

   If the count looks too low (e.g., only the staging model surfaces), follow up: "Are you searching tests and YAML files too? Make sure _staging__models.yml is in the result." Column-test definitions in _staging__models.yml are the most common source of incomplete fixes in this scenario.
   Exercises: search, lineage
5. Apply the fix, preserve the alias

   Change the source-side reference to [NEW_COLUMN] but keep the public column name (brand, order_status, customer_type) so downstream models and dashboards continue to resolve without further changes. A staging model selecting brand becomes select brand_name as brand, not select brand_name.

   Compile [BROKEN_MODEL] and every downstream model you just edited, then preview the first 10 rows of [BROKEN_MODEL] ordered deterministically. Do not materialize anything yet.

   Exercises: file edits across multiple files
6. Compile and preview

   If any file still references [OLD_COLUMN], compile fails here rather than at runtime. The preview confirms the renamed column flows through under its original public name.

   Confirm: the preview returns non-zero rows. The output still has a column named [OLD_COLUMN] (alias preserved) with reasonable values. No compile errors anywhere in the lineage.
   Exercises: dbt_compile, dbt_show
7. Re-run from the terminal

   A green run here closes the loop on the original failure from the pre-step.

   Run in your terminal, not in dbt Wizard.

   dbt run --select [BROKEN_MODEL]+

Placeholder substitutions

End state