dbt-labs / dbt-labs/dbt

[v2 Bug] Snowflake external-stage sources break static analysis (dbt1014) and column-lineage (dbt1000) — @db.schema.stage/path/ treated as a normal relation name

Open
#15,962 0 comments 0 reactions 0 assignees View on GitHub
area:static-analysis engine:v2 status:triage type:bug
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.