risingwavelabs/risingwave · error · ExprError

Array error: {0}

Error message

Array error: {0}

What it means

ExprError::Array wraps ArrayError (via `#[from]`) with the message 'Array error: {0}'. It surfaces lower-level array-type failures (dimension mismatches, index out of bounds on array construction/access, invalid array literal) as expression-evaluation errors. Because it uses `#[from]`, any `ArrayError` returned inside expression code is converted automatically.

Source

Thrown at src/expr/core/src/error.rs:81

    #[error("Numeric out of range: overflow")]
    NumericOverflow,

    #[error("Division by zero")]
    DivisionByZero,

    #[error("Parse error: {0}")]
    // TODO(error-handling): should prefer use error types than strings.
    Parse(Box<str>),

    #[error("Invalid parameter {name}: {reason}")]
    // TODO(error-handling): should prefer use error types than strings.
    InvalidParam {
        name: &'static str,
        reason: Box<str>,
    },

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

    #[error("More than one row returned by {0} used as an expression")]
    MaxOneRow(&'static str),

    /// TODO: deprecate in favor of `Function`
    #[error(transparent)]
    Internal(
        #[from]
        #[backtrace]
        anyhow::Error,
    ),

    #[error("not a constant")]

View on GitHub (pinned to 6469eb736d)

Solutions

1. Check array dimensions/length before subscripting, e.g. with `cardinality(arr)` or `array_length`.
2. Use a bounds-safe access such as `arr[idx]` only after verifying idx <= cardinality, or coalesce with a default.
3. Normalize nested arrays to a consistent shape before array construction.

Example fix

// before
SELECT arr[5] FROM t; -- arr has length 3
// after
SELECT CASE WHEN cardinality(arr) >= 5 THEN arr[5] ELSE NULL END FROM t;

-- bounds check before array access
SELECT CASE WHEN i <= cardinality(arr) THEN arr[i] ELSE NULL END FROM t;

// Downcast to the wrapped ArrayError for structured handling
if let Some(ExprError::Array(inner)) = err.downcast_ref::<ExprError>() {
    log::warn!("array failure: {inner}");
    return Ok(default);
}

When it happens

Trigger: Evaluating array expressions whose shapes/dimensions don't match (e.g. building a multi-dimensional array from ragged sub-arrays), array subscript access beyond the array length, parsing malformed ARRAY literals like `ARRAY[1,2,'a']` under strict typing.

Common situations: Queries mixing 1-D and 2-D arrays, indexing arrays with positions beyond their size, ingesting JSON/protobuf data converted to arrays with inconsistent nesting.

Related errors

• Chunk operation error: {0}
• Failed to decode prost: field not found `{}`
• Must have exactly 1 buffer in a jsonb array
• Must have no buffer in a list array
• Must have at least one element in offsets

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