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

  1. Implement the `Starburst` match arm in `create_static_relation`, constructing the appropriate `RelationStatic`/`StaticBaseRelationObject` (Starburst is Trino-based, so mirror the Trino quoting/behavior)
  2. Until implemented, guard callers: reject or fall back for `AdapterType::Starburst` before calling `create_static_relation`
  3. 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

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.