dbt-labs/dbt-core · error

Adapter should be available during parse phase

Error message

Adapter should be available during parse phase

What it means

A panic from `.expect()` in `collect_adapter_identifiers_detect_unsafe` (called by `resolve_models`, `resolve_snapshots`, `resolve_data_tests`). Before chunked model rendering, the code fetches the adapter from the Jinja environment to scan for unsafe identifiers; if no adapter was attached to the environment, resolution cannot proceed and it panics. Adapter presence during parse is a hard requirement of these resolution paths.

Source

Thrown at crates/dbt-parser/src/renderer.rs:829

    node_resolver: &NodeResolver,
    jinja_env: Arc<JinjaEnv>,
    adapter_type: AdapterType,
    package_name: &str,
    root_project_name: &str,
    runtime_config: Arc<DbtRuntimeConfig>,
    token: &CancellationToken,
) -> FsResult<Vec<(T, bool)>> {
    if node_map.is_empty() {
        return Ok(Vec::new());
    }

    let max_concurrency = crate::parallel::effective_parallelism(arg.no_parallel);
    let model_vec: Vec<(String, T)> = node_map.into_iter().collect();
    let chunk_size = model_vec.len().div_ceil(max_concurrency);

    let parse_adapter = jinja_env
        .get_adapter()
        .expect("Adapter should be available during parse phase");

    let chunks = chunk_vec(model_vec, chunk_size);

    let arg = Arc::new(arg.clone());
    let node_resolver = Arc::new(node_resolver.clone());
    let package_name = package_name.to_string();
    let root_project_name = root_project_name.to_string();
    let token = token.clone();

    let chunk_results =
        crate::parallel::dispatch_maybe_parallel(chunks, max_concurrency > 1, move |chunk| {
            let arg = arg.clone();
            let node_resolver = node_resolver.clone();
            let jinja_env = jinja_env.clone();
            let package_name = package_name.clone();
            let root_project_name = root_project_name.clone();
            let runtime_config = runtime_config.clone();
            let parse_adapter = parse_adapter.clone();

View on GitHub (pinned to 0267ce9170)

Solutions

1. Attach the adapter to the Jinja environment before calling any resolve_* function
2. Use the standard parse pipeline (parse/resolve entry points) that guarantees adapter wiring
3. Assert adapter presence early in your harness to fail fast with a clear message
4. Check adapter construction logs for earlier silent failures

Example fix

// before
let jinja_env = JinjaEnv::new(...);
resolve_models(&jinja_env, ...); // panics: no adapter

// after
let jinja_env = Jinja_env::new(...);
jinja_env.set_adapter(adapter.clone());
resolve_models(&jinja_env, ...);

if jinja_env.get_adapter().is_none() {
    return Err("adapter must be attached to the Jinja env before resolve_*".into());
}

fn adapter_attached(env: &JinjaEnv) -> bool {
    env.get_adapter().is_some()
}

When it happens

Trigger: Calling `resolve_models`/`resolve_snapshots`/`resolve_data_tests` with a Jinja env created via `get_adapter()` returning None — i.e., the environment was built without `set_adapter` or the adapter was cleared before resolution.

Common situations: Embedding dbt-parser's resolution APIs in tooling/tests without full adapter bootstrapping; refactors that delay adapter attachment; adapter initialization failures silently swallowed earlier in setup.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• Adapter must be configured for the parse phase
• Starburst
• Athena
• Trino
• Dremio

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