[CT-2458] [Bug] Package-level model default config taking precedence over model-specific config in another package

[chronitis]

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

In project B, we include project A (which includes models) as a package:

# b/packages.yml
packages:
  - local: ../a

Models in project A have specific config() within the model SQL file:

-- a/models/some_incremental_model.sql
{{ config(materialized="incremental", incremental_strategy="alpha") }}
...

While project B sets a default value for some of the same keys in dbt_project.yml:

# b/dbt_project.yml
models:
  +incremental_strategy: beta

When we compile project B, models in project B behave as expected - they use a incremental_strategy configured in the sql file if set, or the default ("beta") if not. However, models from project A all have their incremental_strategy overwritten with "beta", even if they had a more specific configuration in their SQL file.

This seems surprising, since I expected the more specific config in Project A to "win".

(This is not specific to incremental_strategy, and the same effect can be found with other config keys).

Expected Behavior

Per https://docs.getdbt.com/reference/model-configs#configuring-models, I expect the most specific configuration - within the SQL file in project A - to win, rather than the default package configuration in project B.

Steps To Reproduce

As per the Current behavior above, this appears to require:

1. Two projects, one referenced as a package by the other.
2. SQL files in the first project contain some model-specific config
3. The second project sets a default for the same config key
4. dbt compile shows that the second project's default config wins over the first project's seemingly more specific config.

Relevant log output

No response

Environment

- OS: Ubuntu 20.04
- Python: 3.10.6
- dbt: 1.4.6

Which database adapter are you using with dbt?

redshift

Additional Context

Possibly related to #6705

[jtcohen6]

@chronitis Sorry that this surprised you. This is documented in https://docs.getdbt.com/docs/build/packages:

Configurations made in your dbt_project.yml file will override any configurations in a package (either in the dbt_project.yml file of the package, or in config blocks).

It sounds like we need to update the docs in https://docs.getdbt.com/reference/model-configs (and https://docs.getdbt.com/reference/configs-and-properties) to reflect this fact as well! Another user was recently confused by the same behavior: #7277

The intent of this behavior is to enable users of packages that they don't own/maintain to make changes to models from those packages, without needing to copy-paste-edit the code themselves. Doug offered an excellent and thorough explanation in a comment on the issue linked above:

• [CT-2374] [Bug] global materialization attribute overrides more specific package attributes #7277 (comment)

I'm going to close this issue, and open a docs one instead.

[chronitis]

@jtcohen6 thanks for the quick response and explaining the design decision here.

I had read that page, but I'd clearly not taken in that part. I can see the argument that it makes sense to be able to reconfigure imported models, although I did still find the apparent inversion in precedence surprising.