[Bug] Snapshot configs for schema not being applied

[trevenm]

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

When applying schema config to a snapshot, the resulting build is not influenced. Using target_schema config gives the expected result.

Expected Behavior

Customize the build location of snapshots by providing schema config as illustrated in documentation.

“Standard schema and database configs supported: Snapshots will now be consistent with other dbt resource types. You can specify where environment-aware snapshots should be stored.” source

"Developers can still set a custom location with schema and database configs, consistent with other resource types."
(source)

Example config in docs
Configuring snapshots

Steps To Reproduce

Config

snapshots:
  - name: snapshot__dummy_source
    relation: source('dummy_source','dummy_source')
    config:      
      schema: dbt_tmull_snapshots
      strategy: timestamp
      unique_key: id
      updated_at: load_ts

Result
14:22:43 On snapshot.dbtlabs_treven_snowflake.snapshot__dummy_source: create or replace transient table TREVEN_SANDBOX.snapshots.snapshot__dummy_source

Config

snapshots:
  - name: snapshot__dummy_source
    relation: source('dummy_source','dummy_source')
    config:
      target_schema: dbt_tmull_snapshots
      strategy: timestamp
      unique_key: id
      updated_at: load_ts

Result
14:24:03 On snapshot.dbtlabs_treven_snowflake.snapshot__dummy_source: create or replace transient table TREVEN_SANDBOX.dbt_tmull_snapshots.snapshot__dummy_source

Relevant log output

Environment

- OS: MacOS 15.6.1
- Python: 3.9.6
- dbt: 1.10.13

Initially discovered in dbt platform project, reproduced results in core project.

Which database adapter are you using with dbt?

snowflake

Additional Context

No response

[gshank]

@trevenm Do you have a "generate_schema_name" macro in your "dbtlabs_treven_snowflake" project?

[trevenm]

@gshank I do, and I can see how my test value looks too close to what may be generated. I've removed my custom generate_schema_name macro from my project and repeated the test (in dbt platform) with a more distinct schema value.

Config

snapshots:
  - name: snapshot__dummy_source
    relation: source('dummy_source','dummy_source')
    config:
      schema: test_schema_value
      strategy: timestamp
      unique_key: id
      updated_at: load_ts

Result
22:44:57 On snapshot.dbtlabs_treven_snowflake.snapshot__dummy_source: create or replace transient table TREVEN_SANDBOX.snapshots.snapshot__dummy_source

Config

snapshots:
  - name: snapshot__dummy_source
    relation: source('dummy_source','dummy_source')
    config:
      target_schema: test_schema_value
      strategy: timestamp
      unique_key: id
      updated_at: load_ts

Result
22:45:46 On snapshot.dbtlabs_treven_snowflake.snapshot__dummy_source: create or replace transient table TREVEN_SANDBOX.test_schema_value.snapshot__dummy_source

[jeremyyeo]

Try doing this

-- macros/gsn.sql
{% macro generate_schema_name(custom_schema_name, node) -%}
  {{ 'schema_from_gsn' }}
{%- endmacro %}

# snapshots/snap.yml
snapshots:
  - name: snapshot__dummy_source
    relation: source('dummy_source','dummy_source')
    config:
      schema: test_schema_value # WHATEVER VALUE...
      strategy: timestamp
      unique_key: id
      updated_at: load_ts

Make sure we always build with no partial parse to exclude partial parsing issues:

$ dbt build --no-partial-parse

What schema do you get? I'm expecting the snap to go into schema schema_from_gsn.

I would also make sure the project is void of all unnecessary code / unnecessary packages / etc - i.e. just a single dbt_project.yml, gsn macro override, source and snapshot declaration and nothing else. The string "snapshots" in the snapshot schema must 100% come from some code we've written / config we've set somewhere in your project so just need to find where that is - and sometimes it's a matter of deleting everything until we only have the sufficient minimal code to reproduce the problem :P

^ You can see mine works as expected, when using schema instead of target_schema - the logic uses the gsn macro instead. This is every single piece of dbt code (just 4 files) I had in my project:

# dbt_project.yml
config-version: 2
name: analytics
profile: sf
version: "1.0.0"

models:
  analytics:
    +materialized: table

# snapshots/snap.yml
snapshots:
  - name: snapshot__dummy_source
    relation: ref('foo')
    config:
      schema: test_schema_value  # we expect dbt to use gsn macro logic when using `schema` 
      strategy: timestamp
      unique_key: id
      updated_at: load_ts

-- models/foo.sql
select 1 id, current_timestamp as load_ts

-- macros/gsn.sql
{% macro generate_schema_name(custom_schema_name, node) -%}
  {{ 'schema_from_gsn' }}
{%- endmacro %}

[trevenm]

@jeremyyeo Started a new init project and tested with your method, got the same results as you. Confirms there is something in my other project causing the issue. Thank you for the guidance! I will use this method when exploring issues in the future to isolate behavior from messy sandbox projects. I will close this issue, looks like this does not represent a bug.