[CT-2739] Difference snapshot behaviour between version 1.0 and 1.5

[rrchorly]

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

I have this snapshot

{% snapshot order_snapshots %}

{{
    config(
      alias='<name>_snapshots',
      target_schema= 'dbt_<name>_snapshots',
      unique_key='id',
      strategy='check',
      check_cols='all'
    )
}}

select * from {{ source('jaffle_shop', 'orders') }}

{% endsnapshot %}

and a corresponding schema, snapshot_orders.yml

version: 2

snapshots:
  - name: order_snapshots
    description: orders snapshot
    docs:
      show: true

If I build the snapshot in version 1.5, then it is built in the Dev schema (dbt_) and not the target schema (dbt__snapshots). If I downgrade to version 1.0, and build the snapshot again, it is created in the target schema. I tested this behaviour across multiple versions and looks like the behaviour changed in 1.3 i.e. up until 1.2, the snapshot is created in the target schema.
A workaround is to comment

docs:
      show: true

in the snapshot schema file and this allows the snapshot to be built in the target schema in version 1.5.

Expected/Previous Behavior

The snapshot should get built in the correct schema, defined in its yml file.

Steps To Reproduce

Steps detailed in issue description

Relevant log output

No response

Environment

- OS: Linux
- Python: 3.9
- dbt (working version): 1.0
- dbt (regression version): 1.5

Which database adapter are you using with dbt?

No response

Additional Context

No response

[jtcohen6]

@rrchorly Thanks for opening! Educated guess, I think this may be the same issue as:

• [CT-1913] Snapshot target_schema & target_database used from dbt_project.yml #6745

That is, the yaml config is clobbering the target_schema config set within the snapshot file, and resetting it to the default value.

I'm going to close this as a duplicate, and bump the priority of the linked bug. It's good to know that this is technically a regression from v1.2 → v1.3. At this point, we're most likely to make the fix for the next minor version, and (if the fix is precise enough) patch in one previous minor version.

[rrchorly]

Thanks @jtcohen6