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

argument 'name' to var() has incompatible type; value is not

Error message

argument 'name' to var() has incompatible type; value is not a string

What it means

The `var()` Jinja function requires its `name` argument to be a string. When the first positional argument is neither a string nor undefined/None, `parse_args` rejects it with this error. Non-string values (numbers, lists, dicts, booleans) are not valid variable names.

Source

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

        // NOTE: Minijinja encodes keyword arguments into `args` as a final map value.
        // Using `ArgsIter` ensures we correctly support both:
        // - var("name", "default")
        // - var("name", default="default")
        // and we don't accidentally treat the kwargs map itself as the default value.
        let iter = ArgsIter::new("var", &["name", "default"], args);
        // Jinja will happily pass "undefined" into functions if the caller writes `var(x)`
        // and `x` is not defined. Jinja2's Undefined is string-coercible, so dbt-core will
        // end up treating it like an empty string key and still honor the provided default.
        //
        // For compatibility (and to keep tests/fixtures stable), we explicitly coerce
        // undefined/none to an empty string here instead of raising a type error.
        let var_name_value = iter.next_arg::<Value>()?;
        let var_name = if let Some(s) = var_name_value.as_str() {
            s.to_string()
        } else if var_name_value.is_undefined() || var_name_value.is_none() {
            "".to_string()
        } else {
            return Err(Error::new(
                ErrorKind::InvalidOperation,
                "argument 'name' to var() has incompatible type; value is not a string",
            ));
        };

        // IMPORTANT: ArgsIter's `next_kwarg::<Option<&Value>>` cannot distinguish between:
        // - kwarg missing
        // - kwarg present with value `none`
        //
        // dbt projects commonly do `var("x", default=None)`, so we need to preserve an
        // explicit `none` default.
        //
        // We therefore parse the kwargs map ourselves (if present), and fall back to
        // a true positional default only when the 2nd argument is not that kwargs map.
        let mut default_value: Option<Value> = None;

        // there are two ways for the second argument to be a map:
        // 1. var("x", {"a": 1})

View on GitHub (pinned to 0267ce9170)

Solutions

1. Quote the variable name: `var('my_var')` instead of `var(my_var)`.
2. Convert dynamic names to strings before calling: `var(other | string)`.
3. Ensure the value you intend to pass as a name is actually the key, not the value, of your vars mapping.

Example fix

// before (Jinja)
{{ var(config.cluster_id) }}
// after
{{ var(config.cluster_id | string) }}

{% if my_key is string %}{{ var(my_key) }}{% else %}{{ exceptions.raise_compiler_error('var name must be a string') }}{% endif %}

// Jinja
{% macro safe_var(name) %}
  {% if name is not string %}{{ exceptions.raise_compiler_error('var() name must be a string') }}{% endif %}
  {{ var(name | string) }}
{% endmacro %}

When it happens

Trigger: Calling `{{ var(123) }}`, `{{ var(some_dict) }}`, or `{{ var(config.some_list) }}` — i.e. the first argument to `var()` evaluates to a non-string, non-None minijinja Value.

Common situations: Passing a numeric or boolean var name built from another context value; forgetting quotes so Jinja resolves an identifier instead of a literal string; a `vars` dict lookup producing a non-string key.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

• Required var '{}' not found in config: Vars supplied to {} =
• argument 'name' to has_var() has incompatible type; value is
• describe_dynamic_table is not supported by the {} adapter
• describe_interactive_table is not supported by the {} adapte
• The 'statement' result named '{name}' has already been loade

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