dbt-labs/dbt-core · error

Failed to get parse adapter

Error message

Failed to get parse adapter

What it means

A panic from `jinja_env.get_adapter().expect("Failed to get parse adapter")` while resolving source definitions. During source resolution the parser needs the adapter (database type/relation quoting rules) to call `generate_relation_name` for each source table. The Jinja environment is expected to always carry a parse-time adapter at this point; if it does not, this internal invariant is broken and the parser panics rather than silently generating malformed relation names.

Source

Thrown at crates/dbt-parser/src/resolve/resolve_sources.rs:414

        let user_quoting = DbtQuoting::merge_user(source.quoting.as_ref(), table.quoting.as_ref());

        let mut table_quoting = user_quoting.unwrap_or_default();
        table_quoting.default_to(&source_default_quoting);
        let quoting_ignore_case = table_quoting.snowflake_ignore_case.unwrap_or(false);

        let (database, schema, raw_identifier) =
            resolve_relation_parts(&source, &table, &table_name, database);
        let (database, schema, identifier, quoting) = normalize_quoting(
            &table_quoting.try_into()?,
            adapter_type,
            &database,
            &schema,
            &raw_identifier,
        );

        let parse_adapter = jinja_env
            .get_adapter()
            .expect("Failed to get parse adapter");

        let relation_name =
            generate_relation_name(parse_adapter, &database, &schema, &identifier, quoting)?;

        let columns = if let Some(ref cols) = table.columns {
            process_columns(
                Some(cols),
                source_config.meta.clone(),
                source_config.tags.inner().clone().map(|tags| tags.into()),
            )?
        } else {
            vec![]
        };

        // Validate local sources have data types defined
        use dbt_schemas::schemas::common::SchemaOrigin;
        if source_config.schema_origin == SchemaOrigin::Local {
            if columns.is_empty() {

View on GitHub (pinned to 0267ce9170)

Solutions

1. Ensure the parse adapter is installed on the JinjaEnv (via the env builder/`set_adapter`) before calling `resolve_sources`
2. Verify the correct adapter feature/crate for your warehouse is enabled and initialized (e.g. adapter plugin registration)
3. Check initialization order: adapter setup must precede any parsing/resolution pass
4. If using library APIs directly, use the env-construction helper that guarantees an adapter rather than building a bare JinjaEnv
5. Update parser and adapter crates to matching versions if a refactor changed where the adapter is stored

Example fix

// before
let jinja_env = JinjaEnv::new();
resolve_sources(&jinja_env, ...)?;

// after
let jinja_env = JinjaEnv::new();
jinja_env.set_adapter(parse_adapter.clone());
resolve_sources(&jinja_env, ...)?;

// before resolution
if jinja_env.get_adapter().is_none() {
    return Err(anyhow::anyhow!("JinjaEnv has no parse adapter; install the adapter before resolving sources"));
}

let result = std::panic::catch_unwind(|| resolve_sources(&jinja_env, ...));
match result {
    Ok(res) => res?,
    Err(_) => anyhow::bail!("no parse adapter on JinjaEnv — ensure the adapter is registered before parsing"),
}

When it happens

Trigger: Calling `resolve_sources` with a `JinjaEnv` built without an adapter set (e.g. adapter not registered before resolution), an adapter lookup that returns None because the environment was constructed for a non-adapter context, or a plugin/extension replacing the Jinja environment with a bare one.

Common situations: Custom tooling invoking the parser library directly without wiring the parse adapter into the Jinja environment; an adapter crate/feature not enabled so no adapter is installed; ordering bugs where source resolution runs before adapter initialization; version mismatches between the parser and adapter crates.

Understand the failure class

Background: "X is required", "must be set", "cannot be empty": the missing-required-config error family, from Vertex AI project/location to WeChat keys — this error's family across 18 libraries.

Related errors

• cannot consume EOF
• load_dataframe() for the Salesforce adapter
• Starburst
• Athena
• Trino

AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/6103027392c74baa. Report an issue: GitHub.