[Regression] Parsing error on `dbt-core==1.10.0-a1` when models have a `freshness` config (that follows the source freshness format). `dbt-core~=1.9.0` and prior simply ignored the invalid config.

[jeremyyeo]

Is this a regression in a recent version of dbt-core?

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

Current Behavior

On the main branch (8a8857a as of this writing) - we're running into a parsing error when models have a freshness config. Note that models definitely do not have "freshness" like sources do so the behaviour is kinda correct (see updated comment below - we decided to support model freshness but the format is not the same as source freshness - thus we added validation for this config when there wasn't one before) - but it just so happen that previously (dbt-core <= 1.9.0) simply ignored the freshness config when applied to models and now it is throwing a parsing error.

Users on "latest" in dbt Cloud are suddenly running into this error when they previously did not.

Expected/Previous Behavior

I think it's up to ya'll maintainers to determine the right behaviour but perhaps you want to revert checking that models have an incorrect config freshness - so just make it ignore like previous dbt versions. Or you want to gate this behaviour around a behaviour change flag - (not great for the ever growing matrix of behaviour change flags that we need to maintain). Or perhaps this should have been a "warning" (msg: config freshness is invalid for models) instead of an "parsing error" which breaks runs completely.

Steps To Reproduce

1. Install dbt-core from main.
2. Setup dbt project:

# dbt_project.yml
name: my_dbt_project
profile: all
version: "1.0.0"

models:
  my_dbt_project:
    +materialized: table

# models/schema.yml
models:
  - name: foo
    freshness:
      error_after: {count: 12, period: hour}

-- models/foo.sql
select 1 id

3. Compile

$ dbt compile
21:34:21  Running with dbt=1.10.0-a1
21:34:21  Registered adapter: postgres=1.9.0
21:34:21  Unable to do partial parsing because saved manifest not found. Starting full parse.
21:34:21  Encountered an error:
Parsing Error
  Invalid models config given in models/schemas.yml @ models: {'name': 'foo', 'freshness': {'error_after': {'count': 12, 'period': 'hour'}}, 'original_file_path': 'models/schemas.yml', 'yaml_key': 'models', 'package_name': 'my_dbt_project'} - at path ['freshness']: {'error_after': {'count': 12, 'period': 'hour'}} is not valid under any of the given schemas

4. Downgrade to 1.9 and do the same thing:

$ dbt compile

21:35:02  Running with dbt=1.9.1
21:35:02  Registered adapter: postgres=1.9.0
21:35:02  Unable to do partial parsing because saved manifest not found. Starting full parse.
21:35:02  Found 1 model, 431 macros
21:35:02  
21:35:02  Concurrency: 4 threads (target='pg')
21:35:02

Relevant log output

Environment

- OS: macOS
- Python: 3.11.9
- dbt (working version): ~=1.9.0
- dbt (regression version): 1.10.0-a1

Which database adapter are you using with dbt?

postgres

Additional Context

No response

[jeremyyeo]

Looks like what happens is we added model freshness - when there previously was not. Therefore previously that config would just be ignored and now we validate:

We added "freshness" as an attribute to models; it didn't have it before. So now it gets validated, and the definition of "freshness" in models isn't the same as the definition of "freshness" in source definitions. Miscellaneous non-valid attributes in models mostly just get ignored, which is what happened before.
#11170

[kylash-em]

Hello @jeremyyeo Yes, it's unfortunate that this was suddenly validated in dbt Cloud and caused an unexpected impact, which was quite strange. We had some legacy codebases with freshness tests defined under sources. However, I've now replaced them with recency tests, and everything is working fine.

Reference docs: https://github.com/dbt-labs/dbt-utils?tab=readme-ov-file#recency-source

Hope this helps!

[ogescalante]

We ran into this issue and changed the dbt-cloud config to "Compatible" as there is no way to set the version to 1.8.1 which we use.