[Bug] Updating a data type detail (e.g. size) results in a breaking change on the contract for versioned models

[marvingeerken]

Is this a new bug in dbt-core?

• I believe this is a new bug in dbt-core
• I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

We have a model materialized as a table with an enforced contract and a version 1. If we change a column's data type from varchar(1) to varchar(2), this change is detected as a breaking change.

We already identified that it only happens when a version is added. The materialization does not matter.

Expected Behavior

As described in https://docs.getdbt.com/reference/resource-configs/contract#size-precision-and-scale it should not result in a breaking change.

Steps To Reproduce

1. Create model with a varchar column, an enforced contract and version.

-- bug_mgeerken_dtype_contract.sql
select 'asd' as test_col

models:
  - name: bug_mgeerken_dtype_contract
    config:
      contract:
        enforced: true
    versions:
      - v: 1
    columns:
      - name: test_col
        data_type: varchar(3)

2. Deploy to staging/production deployment environment.

3. Change the varchar size on that contract and run deferring to the previous state.

data_type: varchar(3) --> data_type: varchar(4)

Relevant log output

10:27:08 Encountered an error:
Breaking change to contract Error in model bug_mgeerken_dtype_contract (models/custom/bugs/bug_mgeerken_dtype_contract.sql)
  While comparing to previous project state, dbt detected a breaking change to an enforced contract.
    - Columns with data_type changes: 
      - test_col (varchar(3) -> varchar(4))
  Consider making an additive (non-breaking) change instead, if possible.
  Otherwise, create a new model version: https://docs.getdbt.com/docs/collaborate/govern/model-versions

Environment

dbt Cloud: Latest (2025.2.11+cf5e53e)

Which database adapter are you using with dbt?

snowflake

Additional Context

It might be related to the following release:

• https://github.com/dbt-labs/dbt-core/releases/tag/v1.9.0
• Do not update varchar column definitions if a contract exists ([Bug] Incorrect column data type with incremental contracted model and varchar data_type #10362)
• [Bug] Incorrect column data type with incremental contracted model and varchar data_type #10362

[aranke]

@marvingeerken Thanks for the report here!

Can you please provide some more context about the model, such as whether it is an incremental model?

I'm not able to replicate this issue for a non-incremental model on my end.

Thanks!

[marvingeerken]

@aranke Thanks for your feedback. It was a {{ table }}. I validated it in different scenarios and projects before I created this issue. However, I just tested it again and don't get the error anymore. With the cloud's latest version its hard to reproduce it now.

My test was on my own dbt Cloud account. If I face the issue again on my clients projects, I would ping you again. IMO we can close it.

[aranke]

Great, closing the issue for now.
Please feel free to reopen if this happens again.
Thanks!

[marvingeerken]

Hey @aranke! I have identified why I wasn't able to recreate the error outside my clients project. On my test I haven't had a model version added. Can you please investigate again? (I have no permission to reopen the issue. Hope this message finds you well.)

[liamfmck95]

I wondered whether I could add a similar scenario to this issue. I have updated the data type of a column but only it's case (i.e. decimal(6,5) to DECIMAL(6,5)) and this was treated as a breaking change. I also noticed that if I added a space after the comma within the data type, this would also result in a breaking change error. Since this change would not actually cause any breakage in the model, tests or downstream usage, I don't think these types of changes, as well as the initial issue, should be treated as a breaking change.

[joellabes]

@liamfmck95 could you open this as a new feature idea? It's a reasonable point but slightly different from this

[liamfmck95]

Thanks @joellabes , I have added this now #11352