dbt-labs / dbt-core

dbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.
https://getdbt.com
Apache License 2.0
9.66k stars 1.6k forks source link

[Bug] Project level `store_failures` overriding test level config with dbt>=1.7 #10165

Open jeremyyeo opened 4 months ago

jeremyyeo commented 4 months ago

Is this a new bug in dbt-core?

Current Behavior

With the latest 1.7 version - the project level store_failures config is overriding the model/test level store_failures config.

Expected Behavior

The more specific store_failures config (test/model level) should take precedence over the less specific config (project level) as per config inheritance rules https://docs.getdbt.com/reference/configs-and-properties#config-inheritance like it did with dbt-core <= 1.6

Steps To Reproduce

Project setup

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

models:
 my_dbt_project:
    +materialized: table

tests:
  +store_failures: true  # all tests

# models/schema.yml
version: 2
models:
  - name: foo
    columns:
      - name: id
        tests:
          - not_null:
              config:
                store_failures: false

-- models/foo.sql
select 1 id

Using dbt 1.7:

$ dbt --debug build

23:40:22  On test.my_dbt_project.not_null_foo_id.f099b1e59c: /* {"app": "dbt", "dbt_version": "1.7.14", "profile_name": "all", "target_name": "dev", "node_id": "test.my_dbt_project.not_null_foo_id.f099b1e59c"} */

  create  table "postgres"."public_dbt_test__audit"."not_null_foo_id"

    as

  (

select *
from "postgres"."public"."foo"
where id is null

  );

23:40:22  SQL status: SELECT 0 in 0.0 seconds

23:40:22  On test.my_dbt_project.not_null_foo_id.f099b1e59c: /* {"app": "dbt", "dbt_version": "1.7.14", "profile_name": "all", "target_name": "dev", "node_id": "test.my_dbt_project.not_null_foo_id.f099b1e59c"} */
select
      count(*) as failures,
      count(*) != 0 as should_warn,
      count(*) != 0 as should_error
    from (

        select *
        from "postgres"."public_dbt_test__audit"."not_null_foo_id"

    ) dbt_internal_test

Using dbt 1.6

$ dbt --debug build

23:41:15  On test.my_dbt_project.not_null_foo_id.f099b1e59c: /* {"app": "dbt", "dbt_version": "1.6.14", "profile_name": "all", "target_name": "dev", "node_id": "test.my_dbt_project.not_null_foo_id.f099b1e59c"} */
select
      count(*) as failures,
      count(*) != 0 as should_warn,
      count(*) != 0 as should_error
    from (

select id
from "postgres"."public"."foo"
where id is null

    ) dbt_internal_test
23:41:15  SQL status: SELECT 1 in 0.0 seconds

Relevant log output

No response

Environment

- OS: macOS
- Python: 3.11
- dbt: 
dbt-core==1.6.14, dbt-postgres==1.6.14
dbt-core==1.7.14, dbt-postgres==1.7.14

Which database adapter are you using with dbt?

postgres

Additional Context

No response

dbeatty10 commented 4 months ago

Agreed that the more specific store_failures config (test/model level) should take precedence over the less specific config (project level) as per config inheritance rules. 👍

Thanks for reporting this @jeremyyeo !