dbt-labs/dbt-core · error
Starburst
Error message
Starburst
What it means
This is a Rust `todo!()` panic from `create_static_relation` in crates/dbt-adapter/src/relation/factory.rs:27. The function builds a static `StaticBaseRelationObject` for adapters with a dedicated match arm, but the `Starburst` adapter type was never implemented, so reaching that arm unconditionally panics with the message 'Starburst'. It is a deliberate placeholder marking unfinished adapter support, not a runtime-detected failure.
Source
Thrown at crates/dbt-adapter/src/relation/factory.rs:27
use minijinja::Value;
/// Create a static relation value from an adapter type
/// To be used as api.Relation in the Jinja environment
pub fn create_static_relation(
adapter_type: AdapterType,
quoting: ResolvedQuoting,
) -> Option<Value> {
use AdapterType::*;
let result = match adapter_type {
Snowflake | Databricks | Spark | Fabric | DuckDB | LakeCompute | Exasol | Postgres
| Redshift | Salesforce | Bigquery | ClickHouse => {
let relation_type = RelationStatic {
adapter_type,
quoting,
};
StaticBaseRelationObject::new(Arc::new(relation_type))
}
Starburst => todo!("Starburst"),
Athena => todo!("Athena"),
Trino => todo!("Trino"),
Dremio => todo!("Dremio"),
Oracle => todo!("Oracle"),
Datafusion => todo!("Datafusion"),
};
Some(Value::from_object(result))
}
View on GitHub (pinned to 0267ce9170)
Solutions
- Implement the `Starburst` match arm in `create_static_relation`, constructing the appropriate `RelationStatic`/`StaticBaseRelationObject` (Starburst is Trino-based, so mirror the Trino quoting/behavior)
- Until implemented, guard callers: reject or fall back for `AdapterType::Starburst` before calling `create_static_relation`
- Use a non-Starburst adapter type (e.g. Snowflake, BigQuery, Redshift) when exercising the static relation factory
Example fix
// before
Starburst => todo!("Starburst"),
// after
Starburst => {
let relation_type = RelationStatic { adapter_type, quoting };
StaticBaseRelationObject::new(Arc::new(relation_type))
} Defensive patterns
Strategy: validation
Validate before calling
fn supports_static_relation(t: AdapterType) -> bool {
!matches!(t, AdapterType::Starburst)
}
if !supports_static_relation(adapter_type) {
return Err(format!("static relation factory does not support {adapter_type:?} yet"));
} Type guard
fn static_relation_supported(t: AdapterType) -> bool {
!matches!(t, AdapterType::Starburst | AdapterType::Athena | AdapterType::Trino | AdapterType::Dremio | AdapterType::Oracle | AdapterType::Datafusion)
} Try / catch
match std::panic::catch_unwind(|| create_static_relation(adapter_type)) {
Ok(v) => v,
Err(_) => return Err("create_static_relation unimplemented for this adapter"),
} Prevention
- Before routing a profile through the static relation factory, check the adapter type against the list of implemented arms in factory.rs
- Prefer explicit error returns over todo!() when adding new AdapterType variants
- Run the static-relation quote-policy tests with the target adapter type enabled before shipping
- Track unimplemented match arms with a clippy/exhaustiveness check in CI
When it happens
Trigger: Calling `create_static_relation` (exposed via `get_value`, `adapter_api_value`, or the static-relation unit tests) with `adapter_type` resolving to `AdapterType::Starburst`; any dbt-jinja `api.Relation.create`-style invocation for a Starburst profile in a context that routes through the static relation factory.
Common situations: A developer enables a Starburst profile in their profiles.yml and runs a model whose jinja code calls the relation factory; a test author parameterizes static-relation quote-policy tests over all AdapterType variants including Starburst; an adapter matrix sweep iterating every AdapterType hits the unimplemented arm.
Related errors
AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07).
Data as JSON: /api/errors/af84efbf43721739.
Report an issue: GitHub.