What causes "`commit_checkpoint_interval` must be greater than 0" in risingwavelabs/risingwave?

Set `commit_checkpoint_interval` to a positive integer (checkpoints between commits; e.g. 10 for every 10th checkpoint).

risingwavelabs/risingwave · error · SinkError::Config

`commit_checkpoint_interval` must be greater than 0

Error message

`commit_checkpoint_interval` must be greater than 0

What it means

`from_btreemap` validates that `commit_checkpoint_interval` is strictly positive; a value of 0 would mean committing every zero checkpoints, which StarRocks sink semantics forbid, so it raises this `SinkError::Config`. This guards against misconfiguration that would otherwise break the flush/checkpoint loop.

Solutions

Set `commit_checkpoint_interval` to a positive integer (checkpoints between commits; e.g. 10 for every 10th checkpoint).
Remove the option entirely to use the default value defined in StarrocksConfig.
If you need lower latency, reduce the interval to a small positive number rather than 0.

Example fix

-- before
CREATE SINK s FROM mv WITH (connector='starrocks', commit_checkpoint_interval=0, ...);
-- after
CREATE SINK s FROM mv WITH (connector='starrocks', commit_checkpoint_interval=10, ...);

Defensive patterns

Strategy: validation

Validate before calling

// Rust: reject zero before constructing the sink
if let Some(v) = props.get("commit_checkpoint_interval") {
    if v.parse::<u64>().map_or(true, |n| n == 0) { return Err("commit_checkpoint_interval must be > 0".into()); }
}

Try / catch

match StarrocksConfig::from_btreemap(props) {
    Err(e) if e.to_string().contains("commit_checkpoint_interval") => {
        eprintln!("use a positive integer or omit the option for the default");
    }
    other => other,
}

Prevention

Never set 0 expecting 'auto' — omit the option for defaults
Validate numeric option values in tooling before CREATE SINK
Document that the interval counts checkpoints and must be >= 1

When it happens

Trigger: Creating a StarRocks sink with `commit_checkpoint_interval=0` in the WITH options (e.g. misunderstanding that 0 means 'auto' or 'immediate').

Common situations: Users setting 0 expecting 'commit as fast as possible' or to disable the interval; templating tools emitting a default 0; copy-paste from configs where 0 was a valid sentinel.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

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

Appendix: source

Thrown at src/connector/src/sink/starrocks.rs:169

fn default_commit_checkpoint_interval() -> u64 {
    DEFAULT_COMMIT_CHECKPOINT_INTERVAL_WITH_SINK_DECOUPLE
}

impl StarrocksConfig {
    pub fn from_btreemap(properties: BTreeMap<String, String>) -> Result<Self> {
        let config =
            serde_json::from_value::<StarrocksConfig>(serde_json::to_value(properties).unwrap())
                .map_err(|e| SinkError::Config(anyhow!(e)))?;
        if config.r#type != SINK_TYPE_APPEND_ONLY && config.r#type != SINK_TYPE_UPSERT {
            return Err(SinkError::Config(anyhow!(
                "`{}` must be {}, or {}",
                SINK_TYPE_OPTION,
                SINK_TYPE_APPEND_ONLY,
                SINK_TYPE_UPSERT
            )));
        }
        if config.commit_checkpoint_interval == 0 {
            return Err(SinkError::Config(anyhow!(
                "`commit_checkpoint_interval` must be greater than 0"
            )));
        }
        if let Some(0) = config.max_batch_size_bytes {
            return Err(SinkError::Config(anyhow!(
                "`starrocks.max_batch_size_bytes` must be greater than 0"
            )));
        }
        Ok(config)
    }
}

#[derive(Debug, PartialEq, Eq)]
struct LoadRequestSizeDecision {
    finish_current_load: bool,
    next_batch_size_bytes: u64,
}

View on GitHub (pinned to 6469eb736d)