dbt-labs/dbt-core · error

manifest path config missing for manifest node package

Error message

manifest path config missing for manifest node package

What it means

The fallback branch of `path_config_for_package`: for a non-root package, the code looks up the package's own `ManifestPathConfig` and falls back to the root config; if both are missing it panics. Per the adjacent comment, only public models imported via a publication artifact (cross-project mesh) legitimately lack local files; locally-parsed packages (`local:`/`git:`/`registry:`) must always have a registered config, so a panic here signals either a genuinely missing package registration or an unhandled mesh-import node path.

Source

Thrown at crates/dbt-schemas/src/schemas/manifest/manifest.rs:437

///
/// Manifest `path` conformance is package-relative: dependency resources must be normalized
/// using that dependency package's `model-paths`, `test-paths`, etc., not the root project's.
fn path_config_for_package<'a>(
    resolver_state: &'a ResolverState,
    package_name: &str,
) -> &'a ManifestPathConfig {
    let root_config = resolver_state
        .manifest_path_configs
        .get(&resolver_state.root_project_name);
    if package_name == resolver_state.root_project_name {
        return root_config.expect("root manifest path config missing");
    }

    resolver_state
        .manifest_path_configs
        .get(package_name)
        .or(root_config)
        .expect("manifest path config missing for manifest node package")
}

/// True only for public models imported via a publication artifact (cross-project
/// mesh), whose source files don't exist locally. Public models from a
/// locally-parsed package (`local:` / `git:` / `registry:`) always have a
/// `ManifestPathConfig` registered and must keep their real paths so dbt-core
/// can locate the compiled output — matches mantle's behaviour.
fn is_public_model_from_publication(resolver_state: &ResolverState, model: &ManifestModel) -> bool {
    let package = &model.__common_attr__.package_name;
    model.access == Some(Access::Public)
        && &resolver_state.root_project_name != package
        && !resolver_state.manifest_path_configs.contains_key(package)
}

/// dbt-core manifest conformance: `original_file_path` stays project-relative,
/// while `path` is serialized relative to the configured resource root.
///
/// Used for resources with one obvious root list: models, snapshots, seeds,

View on GitHub (pinned to 0267ce9170)

Solutions

1. Verify the referenced package is installed/registered (dependencies.yml + dbt deps) and its name matches the node's package
2. Ensure the package's `ManifestPathConfig` is registered in `resolver_state.manifest_path_configs` during resolution
3. For cross-project mesh public models, confirm the node is recognized by the mesh-import path that tolerates missing local configs

Example fix

// before
.expect("manifest path config missing for manifest node package")
// after
.ok_or_else(|| fs_err!(ErrorCode::InvalidConfig, "no manifest path config for package {}", package_name))?

// before resolution
if !resolver_state.manifest_path_configs.contains_key(package_name)
    && package_name != resolver_state.root_project_name {
    return Err(format!("package {} not registered in resolver state", package_name));
}

fn package_is_registered(state: &ResolverState, pkg: &str) -> bool {
    pkg == state.root_project_name || state.manifest_path_configs.contains_key(pkg)
}

let config = std::panic::catch_unwind(|| path_config_for_package(resolver_state, pkg))
    .ok()
    .and_then(|r| r.ok());

When it happens

Trigger: `build_disabled_map`/`DbtManifest` resolving a node from package `<pkg>` where neither `manifest_path_configs[pkg]` nor the root config exists — package not registered during resolution, typo'd/renamed package name on the node, or a mesh public-model path hitting the non-mesh branch.

Common situations: A node's `package_name` doesn't match any registered project (dependency not installed or renamed); incomplete resolver state after partial parsing; cross-project public model imports in a build that doesn't mark them as mesh imports.

Understand the failure class

Background: "missing required config value" errors: why libraries refuse to start when a configuration key is empty, unset, or blank — this error's family across 48 libraries.

Related errors

• root manifest path config missing
• span is required
• name_span is required
• DbtQuoting should be set
• Unknown or unsupported adapter type

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