risingwavelabs/risingwave · error · BatchError

Expr error: {0}

Error message

Expr error: {0}

What it means

BatchError::Expr converts an ExprError into the batch error type via #[from], displaying as "Expr error: {0}". It is raised when evaluating an expression during batch query execution fails — e.g. unsupported function/operation, invalid arguments, or evaluation errors on a value.

Source

Thrown at src/batch/src/error.rs:57

pub trait Error = std::error::Error + Send + Sync + 'static;

#[derive(Error, Debug, Construct)]
pub enum BatchError {
    #[error("Storage error: {0}")]
    Storage(
        #[backtrace]
        #[from]
        StorageError,
    ),

    #[error("Array error: {0}")]
    Array(
        #[from]
        #[backtrace]
        ArrayError,
    ),

    #[error("Expr error: {0}")]
    Expr(
        #[from]
        #[backtrace]
        ExprError,
    ),

    #[error("Serialize/deserialize error: {0}")]
    Serde(
        #[source]
        #[backtrace]
        BoxedError,
    ),

    #[error("Failed to send result to channel")]
    SenderError,

    #[error(transparent)]
    Internal(

View on GitHub (pinned to 6469eb736d)

Solutions

1. Read the wrapped ExprError message to find the failing expression/operation.
2. Fix the query: use supported argument types/operations, add explicit casts, or guard NULL/edge values (CASE/COALESCE).
3. Check RisingWave docs/function support for the operator used in the batch path.
4. If the expression should be supported, report a bug with the SQL and inner ExprError.

Example fix

// before: unsupported implicit cast in expression
SELECT int_col + varchar_col FROM t;
// after: explicit cast / supported operation
SELECT int_col + varchar_col::INT FROM t;

// SQL: guard risky expressions before execution
SELECT CASE WHEN denom = 0 THEN NULL ELSE num / denom END FROM t;

match result {
    Err(BatchError::Expr(expr_err)) => {
        // map expr_err to a user-facing SQL error with the failing expression
    }
    other => other,
}

When it happens

Trigger: A batch executor evaluates a BoxedExpression whose compute returns Err(ExprError), converted automatically with `?` — e.g. division by zero paths, unsupported operations, bad function arguments at evaluation time.

Common situations: Queries calling functions with unsupported argument types or nullability assumptions; expression evaluation on data that violates expected invariants; using features whose batch expression support is incomplete.

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

• query_epoch not set in distributed lookup join
• Array error: {0}
• multiple errors: {1}
• Unsupported cast: {0} to {1}
• Casting to {0} out of range

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/0b5d364a324dc895. Report an issue: GitHub.