dbt-labs/dbt-core · error · minijinja::Error (InvalidOperation)

Method {method} not found

Error message

Method {method} not found

What it means

This object exposes only a single method, `has_var`; `call_method_impl` errors for any other method name invoked on it. It is the standard minijinja object-protocol fallback when an undefined method is called.

Source

Thrown at crates/dbt-jinja-vars/src/var.rs:152

        args: &[Value],
        _listeners: &[Rc<dyn RenderingEventListener>],
    ) -> Result<Value, Error> {
        let (var_name, default_value) = Self::parse_args(args)?;
        self.call_as_function(state, var_name, default_value)
    }

    /// Common implementation for `Object::call_method`.
    fn call_method_impl(
        self: &Arc<Self>,
        state: &State<'_, '_>,
        method: &str,
        args: &[Value],
        _listeners: &[Rc<dyn RenderingEventListener>],
    ) -> Result<Value, Error> {
        if method == "has_var" {
            self.call_has_var(state, args)
        } else {
            Err(Error::new(
                ErrorKind::InvalidOperation,
                format!("Method {method} not found"),
            ))
        }
    }
}

/// A struct that returns a variable from a map of variables (with optional overrides)
/// https://github.com/dbt-labs/dbt-core/blob/31881d2a3bea030e700e9df126a3445298385698/core/dbt/context/base.py#L139
#[derive(Debug)]
pub struct Var {
    vars: BTreeMap<String, dbt_yaml::Value>,
    overrides: Option<BTreeMap<String, dbt_yaml::Value>>,
}

impl Var {
    /// Make a new Var struct
    pub fn new(vars: BTreeMap<String, dbt_yaml::Value>) -> Self {

View on GitHub (pinned to 0267ce9170)

Solutions

  1. Use `has_var('name')` for existence checks and `var('name', default)` for value access.
  2. Iterate supplied vars via the invocation `vars` argument (`dbt run --vars`), not via dict methods on this object.
  3. Fix typos — the method name is exactly `has_var`.

Example fix

// before (Jinja)
{{ vars.get('my_var', 'default') }}
// after
{% if has_var('my_var') %}{{ var('my_var') }}{% else %}default{% endif %}
Defensive patterns

Strategy: validation

Validate before calling

{% if not method_name in ['has_var'] %}{{ exceptions.raise_compiler_error('only has_var is supported') }}{% endif %}

Prevention

When it happens

Trigger: Invoking any method other than `has_var` on this Jinja object, e.g. `{{ vars.get('x') }}`, `{{ vars.items() }}`, or misspellings like `{{ vars.hasvar('x') }}` / `{{ vars.has_var_x }}`.

Common situations: Treating the vars object like a Python dict (calling `.get`, `.keys`, `.items`); typo'd method names; expecting `has_var` to exist on a different context object.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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