[v2 Bug] Snowflake external-stage sources break static analysis (dbt1014) and column-lineage (dbt1000) — @db.schema.stage/path/ treated as a normal relation name
- Dominant language
- Rust
- Stars
- 13.8k
- Forks
- 2.6k
- Avg merge
- 21h 31m
- Merged PRs (30d)
- 56
Description
### Is this a new bug in dbt v2.x compared to the latest version of dbt 1.x?
- [x] I believe this is a new bug in dbt v2.x
- [x] I have searched the existing issues and could not find a duplicate
### Current Behavior
A dbt source pointing at a Snowflake external stage (@stage in database, stage path in identifier) fails in Fusion. The rendered name @my_db.my_schema.my_stage/path/to/data/ triggers two errors:
- dbt1014 — Fusion runs describe table @my_db.my_schema.my_stage/path/to/data/ to fetch the source schema; Snowflake rejects the syntax, so Fusion turns static analysis off for the model.
https://github.com/dbt-labs/dbt-core/blob/008b19a073dcf706101d3cde9158416052c6b456/crates/dbt-loader/src/dbt_macro_assets/dbt-snowflake/macros/adapters.sql#L33
- dbt1000 — the column-lineage parser can't parse the name because / isn't a valid identifier char: unexpected input after identifier /path/to/data/.
https://github.com/dbt-labs/dbt-core/blob/008b19a073dcf706101d3cde9158416052c6b456/crates/dbt-frontend-common/src/dialect.rs#L245
Both worked in dbt Core (Python), which only string-interpolated the name into SQL and never parsed or introspected it.
### Expected Behavior
Fusion should recognize @-prefixed stage references and not treat them as ordinary catalog.schema.identifier names — skipping them (or handling stage syntax) in both the schema-download and column-lineage paths, the same way it already skips them in the run-cache path:
https://github.com/dbt-labs/dbt-core/blob/008b19a073dcf706101d3cde9158416052c6b456/crates/dbt-tasks-core/src/run_cache/run_cache_service.rs#L4111
A valid stage source should compile with static analysis on and without lineage/parse errors.
### Steps To Reproduce
1. Add a source pointing at a Snowflake external stage:
```yml
sources:
- name: stage_src
database: "@my_db"
schema: my_schema
tables:
- name: stage_tbl
identifier: "my_stage/path/to/data/"
```
2. Add a view that reads it:
```jinja
{{
config(materialized='view')
}}
select *
from {{ source('stage_src', 'stage_tbl') }}
```
3. Run:
`dbt compile --select stage_view --static-analysis strict --write-index --write-lineage`
4. Observe dbt1014 (schema download fails, static analysis disabled) and dbt1000 (column-lineage parse failure) for the stage source.
### Relevant log output
```shell
```
### Environment
```markdown
fusion version 210
```
### Which database adapter are you using?
snowflake
### Is this a discrepancy vs. dbt 1.x?
- [x] Yes — this works in dbt 1.x but not in dbt v2.x
### Additional Context
for ref, this was a "claude investigated" issue, but the gist of the issue isn't new
It would be nice if there was first class support for stages as a yml key in future
`sources.yml` -> `sources:`
`stages.yml` -> `stages:`
Contributor guide
Assessment
This issue has not been assessed yet.