risingwavelabs/risingwave · error · ExprError

Invalid parameter {name}: {reason}

Error message

Invalid parameter {name}: {reason}

What it means

ExprError::InvalidParam { name, reason } signals that a named parameter passed to an expression or function is invalid, with `name` identifying the offending parameter and `reason` explaining why. It exists so function implementations can reject bad inputs with a precise message rather than an opaque string error. Like Parse, the TODO notes it should eventually use structured error types.

Source

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

    CastOutOfRange(&'static str),

    #[error("Numeric out of range")]
    NumericOutOfRange,

    #[error("Numeric out of range: underflow")]
    NumericUnderflow,

    #[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)]

View on GitHub (pinned to 6469eb736d)

Solutions

1. Read the `name`/`reason` in the message and correct that specific argument.
2. Check the function's documentation for the accepted domain of the parameter.
3. Validate user-supplied parameter values in application code or SQL before invoking the function.

Example fix

// before
SELECT date_trunc('centuryish', ts) FROM t;
// after
SELECT date_trunc('century', ts) FROM t;

-- validate parameter domain before call
SELECT CASE WHEN tz IN ('UTC','America/New_York', ...) THEN date_trunc('day', ts, tz) ELSE NULL END FROM t;

// Extract name/reason for a precise user message
let err = result.err() else { return Ok(()) };
let msg = err.to_string(); // "Invalid parameter <name>: <reason>"
reject(msg);

When it happens

Trigger: Calling an expression function with an out-of-range, malformed, or semantically invalid argument that the function validates by name (e.g. an invalid timezone name, an invalid format string, a negative argument where positive is required).

Common situations: Typos in function arguments, unsupported timezone/format specifiers, invalid options passed to string/date functions, copy-pasted arguments that don't fit the new call site.

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

• Invalid value `{value}` for `{entry}`
• 'copy-on-write' mode is not supported for append-only iceber
• order_key must not be empty
• System column `{}` is not allowed in order_key
• Unknown fields in the WITH clause: {:?}

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