risingwavelabs/risingwave · error

value {:?} out of range, expect {:?}

Error message

value {:?} out of range, expect {:?}

What it means

When altering a database's barrier_interval_ms parameter, RisingWave validates the proposed value against the allowed range via OverrideValidate::barrier_interval_ms (backed by expect_range in src/common/src/system_param/mod.rs:281). If the provided u64 value falls outside the supported range, the validation returns this formatted string which alter_database_param wraps into an anyhow error. It prevents parameters that would overflow the i32 storage column or produce nonsensical barrier intervals.

Source

Thrown at src/meta/src/controller/catalog/alter_op.rs:836

    }

    pub async fn alter_database_param(
        &self,
        database_id: DatabaseId,
        param: AlterDatabaseParam,
    ) -> MetaResult<(NotificationVersion, risingwave_meta_model::database::Model)> {
        let inner = self.inner.write().await;
        let txn = inner.db.begin().await?;

        let mut database = database::ActiveModel {
            database_id: Set(database_id),
            ..Default::default()
        };
        match param {
            AlterDatabaseParam::BarrierIntervalMs(interval) => {
                if let Some(ref interval) = interval {
                    OverrideValidate::barrier_interval_ms(interval)
                        .map_err(|e| anyhow::anyhow!(e))?;
                }
                database.barrier_interval_ms = Set(interval.map(|i| i as i32));
            }
            AlterDatabaseParam::CheckpointFrequency(frequency) => {
                if let Some(ref frequency) = frequency {
                    OverrideValidate::checkpoint_frequency(frequency)
                        .map_err(|e| anyhow::anyhow!(e))?;
                }
                database.checkpoint_frequency = Set(frequency.map(|f| f as i64));
            }
        }
        let database = database.update(&txn).await?;

        let obj = Object::find_by_id(database_id)
            .one(&txn)
            .await?
            .ok_or_else(|| MetaError::catalog_id_not_found("database", database_id))?;

View on GitHub (pinned to 6469eb736d)

Solutions

1. Check the current accepted range and pass a barrier_interval_ms within it.
2. Confirm the unit is milliseconds (not seconds) and the value fits in i32.
3. Omit the parameter (pass None) to keep the existing/default value.

Example fix

// before
ALTER DATABASE mydb SET barrier_interval_ms = 999999999999;
// after
ALTER DATABASE mydb SET barrier_interval_ms = 250;

// Rust
fn valid_barrier_interval_ms(v: u64) -> bool {
    // must fit i32 and satisfy system param range
    v <= i32::MAX as u64 && v > 0
}
assert!(valid_barrier_interval_ms(250));

fn fits_i32(v: u64) -> Option<i32> { i32::try_from(v).ok() }

match controller.alter_database_param(db_id, AlterDatabaseParam::BarrierIntervalMs(Some(v))).await {
    Err(e) if e.to_string().contains("out of range") => eprintln!("pick a value within the allowed barrier_interval_ms range"),
    other => other?,
}

When it happens

Trigger: Calling ALTER DATABASE ... barrier_interval_ms (or the alter_database_param catalog API) with a u64 value outside the accepted range for barrier_interval_ms, e.g. an enormous millisecond value that would not fit in i32 or violates the configured min/max bounds.

Common situations: Copy-pasting a config value in seconds instead of milliseconds; scripting DDL with an unbounded computed value; using a value from an older cluster version whose accepted range differs.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

• value {:?} out of range, expect {:?}
• since_timestamp is not before the committed epoch of upstrea
• since_timestamp is too new for upstream table {}: requested
• database {} unavailable {}
• database {} not found when resolving reschedule intent

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