dbt-labs/dbt-core · error · minijinja::Error (InvalidOperation)
Package vars should be initialized for package: {package_nam
Error message
Package vars should be initialized for package: {package_name} What it means
`ConfiguredVar::contains_var` resolves the package name and then requires an entry in the pre-initialized `vars` map for that package. This error is thrown when no package-vars map was initialized for the resolved package, meaning the caller never populated namespace vars before checking `var` existence. It's an initialization-contract error rather than a user-data problem.
Source
Thrown at crates/dbt-jinja-vars/src/configured_var.rs:70
.lookup(TARGET_PACKAGE_NAME, &[])
.and_then(|value| value.as_str().map(str::to_string))
})
.ok_or_else(|| {
Error::new(
ErrorKind::InvalidOperation,
format!(
"'TARGET_PACKAGE_NAME' should be set. Missing in configured var context while looking up var: {var_name}"
),
)
})
}
}
impl VarFunction for ConfiguredVar {
fn contains_var(&self, state: &State<'_, '_>, var_name: &str) -> Result<bool, Error> {
let package_name = self.package_name(state, var_name)?;
let vars_lookup = self.vars.get(&package_name).ok_or_else(|| {
Error::new(
ErrorKind::InvalidOperation,
format!("Package vars should be initialized for package: {package_name}"),
)
})?;
Ok(vars_lookup.contains_key(var_name))
}
fn call_as_function(
&self,
state: &State<'_, '_>,
var_name: String,
default_value: Option<Value>,
) -> Result<Value, Error> {
// 1. CLI vars
if let Some(value) = self.cli_vars.get(&var_name) {
return Ok(cli_var_value_to_minijinja(value));
}
// 2. Check if this is dbt_project.yml parsingView on GitHub (pinned to 0267ce9170)
Solutions
- Initialize the vars map for every package (including empty maps) before evaluating templates that call var()/contains_var().
- Verify the package name resolved from TARGET_PACKAGE_NAME matches a package you actually initialized vars for.
- Check the vars-collection phase completed before the template evaluation.
Example fix
// before
let vars = HashMap::from([("root_pkg".to_string(), root_vars)]);
// after
let vars = HashMap::from([
("root_pkg".to_string(), root_vars),
("dep_pkg".to_string(), dep_vars), // ensure every package has an entry (possibly empty)
]);
Defensive patterns
Strategy: validation
Validate before calling
// pre-check before evaluation
fn all_packages_initialized(vars: &HashMap<String, HashMap<String, Value>>, pkgs: &[String]) -> bool {
pkgs.iter().all(|p| vars.contains_key(p))
} Try / catch
match result {
Err(e) if e.to_string().contains("Package vars should be initialized") => {
// initialize vars map for the missing package and re-evaluate
}
other => other,
} Prevention
- Insert an (possibly empty) vars entry for every package during context construction.
- Ensure var collection completes before template evaluation.
- Validate that package names from TARGET_PACKAGE_NAME match registered keys.
When it happens
Trigger: Calling `contains_var(state, var_name)` (backing `var(...) is none` style checks) when `ConfiguredVar.vars` has no entry for the package resolved from TARGET_PACKAGE_NAME — e.g. a package with no vars ever registered.
Common situations: Cross-package var checks where the dependency package never had vars initialized; tooling that constructs ConfiguredVar with only the root package's vars; parse-time checks before vars collection completes.
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
- Method {method} not found
- Failed to get parse adapter
- RelationConfigBaseObject does not support method: {}
- {} relation creation from Jinja values
- group_by with function key
AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07).
Data as JSON: /api/errors/9d04f803ff2b3274.
Report an issue: GitHub.