dbt-labs/dbt-core · error

macro still present

Error message

macro still present

What it means

Test assertion "macro still present" panics when `macros.get(&unique_id)` returns None after applying macro patches in test_apply_macro_patches_populates_config_meta_and_docs. It verifies that apply_macro_patches never removes or renames the patched macro's entry in the macros map.

Source

Thrown at crates/dbt-parser/src/resolve/resolve_macros.rs:942

            relative_path: PathBuf::from("macros/schema.yml"),
            schema_value,
            table_value: None,
            version_info: None,
            duplicate_paths: vec![],
        };
        let macro_properties = BTreeMap::from([("my_macro".to_string(), props_entry)]);

        apply_macro_patches(
            &mut macros,
            &macro_properties,
            "test_pkg",
            &jinja_env,
            &base_ctx,
            None,
            false,
        )?;

        let patched = macros.get(&unique_id).expect("macro still present");

        // config.meta mirrors the patched meta
        let owner = patched
            .config
            .meta
            .get("owner")
            .expect("owner key in config.meta");
        assert_eq!(owner.as_str(), Some("alice"));

        // config.docs mirrors the patched docs (show: false)
        assert!(
            !patched.config.docs.show,
            "config.docs.show should be false"
        );

        Ok(())
    }

View on GitHub (pinned to 0267ce9170)

Solutions

1. Print/inspect the keys of the macros map after apply_macro_patches and compare against unique_id to find the key mismatch.
2. Ensure the test fixture macro's name/package produces the same unique_id used for the lookup.
3. Check that apply_macro_patches inserts the patched macro rather than only mutating config in place.

// after apply_macro_patches
assert!(macros.contains_key(&unique_id), "patch key {} missing; keys: {:?}", unique_id, macros.keys().collect::<Vec<_>>());

When it happens

Trigger: apply_macro_patches (called with &jinja_env, &base_ctx, None, false) fails to insert/retain the macro keyed by unique_id, so the subsequent map lookup yields None.

Common situations: A change to patch keying (e.g., switching from name to unique_id, or package-qualified IDs) makes the patch land under a different key; the patch fixture macro name was renamed so no entry is created.

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

• warning should retain its FsError
• owner key in config.meta
• cannot consume EOF
• The `start_paused` option requires the `current_thread` runt
• The `unhandled_panic` option requires the `current_thread` r

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