What causes "bytes.per.second expect usize" in risingwavelabs/risingwave?

Set `bytes.per.second` to a plain integer literal, e.g. `bytes.per.second = '1048576'`.

bytes.per.second expect usize

Error message

bytes.per.second expect usize

What it means

In `KafkaSplitReader::new` (src/connector/src/source/kafka/source/reader.rs:180), the developer-only tuning option `bytes.per.second` must parse as a `usize`. It is only used for performance testing, so the code intentionally panics via `.expect("bytes.per.second expect usize")` instead of returning a recoverable error when the value is missing a valid integer or is out of usize range.

Solutions

Set `bytes.per.second` to a plain integer literal, e.g. `bytes.per.second = '1048576'`.
Remove the `bytes.per.second` option entirely if not doing performance testing (defaults to usize::MAX, i.e. unlimited).
For large rates, ensure the integer fits in usize (64-bit on typical platforms).

Example fix

// before (WITH option)
bytes.per.second = '10MB'
// after
bytes.per.second = '10485760'

Defensive patterns

Strategy: validation

Validate before calling

// Pre-validate the WITH option before CREATE SOURCE
let bps: Option<usize> = props.bytes_per_second.as_ref().map(|s| {
    s.parse().expect("bytes.per.second must be a plain integer (no unit suffixes)")
});

Try / catch

// This path panics (expect), not returns Result; guard at construction
let bps = props.bytes_per_second.as_deref()
    .map(str::parse::<usize>)
    .transpose()
    .map_err(|_| anyhow!("bytes.per.second expect usize"))?;

Prevention

Always pass plain decimal integers, never '10MB'/'1e6' style values
Omit the option entirely unless doing performance testing
Add SQL-side validation of the option before source creation in your tooling

When it happens

Trigger: Creating a Kafka source with `bytes.per.second` set to a non-numeric string (e.g. `'10MB'`, `'abc'`) or a value larger than usize::MAX, while the option is Some.

Common situations: Performance testing setups where a developer writes a human-readable rate like `'10mb'` or `'1048576b'` instead of a plain integer, assuming unit suffixes are supported.

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/505f520ac7ed0de9. Report an issue: GitHub.

Appendix: source

Thrown at src/connector/src/source/kafka/source/reader.rs:180

        tracing::info!(
            topic = properties.common.topic,
            source_name = source_ctx.source_name,
            fragment_id = %source_ctx.fragment_id,
            source_id = %source_ctx.source_id,
            actor_id = %source_ctx.actor_id,
            "backfill_info: {:?}",
            backfill_info
        );

        consumer.assign(&tpl)?;

        // The two parameters below are only used by developers for performance testing purposes,
        // so we panic here on purpose if the input is not correctly recognized.
        let bytes_per_second = match properties.bytes_per_second {
            None => usize::MAX,
            Some(number) => number
                .parse::<usize>()
                .expect("bytes.per.second expect usize"),
        };
        let max_num_messages = match properties.max_num_messages {
            None => usize::MAX,
            Some(number) => number
                .parse::<usize>()
                .expect("max.num.messages expect usize"),
        };

        Ok(Self {
            consumer,
            offsets,
            splits,
            backfill_info,
            known_eof_offsets,
            bytes_per_second,
            sync_call_timeout: properties.common.sync_call_timeout,
            max_num_messages,
            parser_config,

View on GitHub (pinned to 6469eb736d)