cube-js/cube · error · minijinja::Error

Converting from {:?} to Python is not supported

Error message

Converting from {:?} to Python is not supported

What it means

`from_minijinja_value` converts MiniJinja values into Python (`CLRepr`) values. Numbers are tried as `i64` then `f64`; if the value is a `Number` kind but fits neither (or conversion fails at the TryInto level), it raises this `InvalidOperation` error. It can also be raised for unsupported kinds via the same-format catch-all at line 97.

Source

Thrown at packages/cubejs-backend-native/src/template/mj_value/python.rs:26

use minijinja as mj;
use minijinja::value as mjv;
use minijinja::value::{Object, ObjectKind, StructObject, Value};
use pyo3::types::{PyDict, PyDictMethods, PyFunction};
use pyo3::{Py, PyObject, PyResult, Python};
use std::convert::TryInto;
use std::sync::Arc;

pub fn from_minijinja_value(from: &mjv::Value) -> Result<CLRepr, mj::Error> {
    match from.kind() {
        mjv::ValueKind::Undefined | mjv::ValueKind::None => Ok(CLRepr::Null),
        mjv::ValueKind::Bool => Ok(CLRepr::Bool(from.is_true())),
        mjv::ValueKind::Number => {
            if let Ok(rv) = TryInto::<i64>::try_into(from.clone()) {
                Ok(CLRepr::Int(rv))
            } else if let Ok(rv) = TryInto::<f64>::try_into(from.clone()) {
                Ok(CLRepr::Float(rv))
            } else {
                Err(mj::Error::new(
                    mj::ErrorKind::InvalidOperation,
                    format!("Converting from {:?} to Python is not supported", from),
                ))
            }
        }
        mjv::ValueKind::String => Ok(CLRepr::String(
            from.as_str()
                .expect("ValueKind::String must return string from as_str()")
                .to_string(),
            if from.is_safe() {
                StringType::Safe
            } else {
                StringType::Normal
            },
        )),
        mjv::ValueKind::Seq => {
            let seq = if let Some(seq) = from.as_seq() {
                seq

View on GitHub (pinned to 7d981676b3)

Solutions

1. Check the `{:?}` debug dump in the message to see the actual value/kind.
2. Avoid passing integers beyond i64 range into Python filters; cast to float or string in the template.
3. Don't pass undefined/function template values to Python callables.
4. Handle the value in Jinja (e.g. `|string`) before invoking the Python filter.

Example fix

// before
{{ big_number | py_filter }}
// after
{{ big_number | string | py_filter }}

// in template, before passing a number to a Python filter:
{% if v is number %}{{ v | py_filter }}{% endif %}

fn is_py_safe_number(v: i128) -> bool {
    v >= i64::MIN as i128 && v <= i64::MAX as i128
}

match from_minijinja_value(&val) {
    Err(e) if e.to_string().contains("not supported") => {
        // fall back to string/JSON conversion path
    }
    other => other?,
}

When it happens

Trigger: A Python filter/method receives a MiniJinja number that is neither integer- nor float-convertible (e.g. an out-of-range huge integer like u64 > i64::MAX), or a non-numeric kind reaching the unsupported branch (e.g. undefined, invalid, function values).

Common situations: Passing very large integers from a template into a Python filter (i64 overflow), passing template functions/undefined values as arguments, or Python interop over a value produced by an upstream template error.

Related errors

• Unable to convert Seq to Python
• Unable to convert Map to Python object: key must be string,
• Error while calling filter: {}
• function registration must be used with functions, actual: '
• unable to register variable: name '%s' is already in use for

AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02). Data as JSON: /api/errors/34610276c05e79e3. Report an issue: GitHub.