risingwavelabs/risingwave · error

invalid state, new_count = 0 and is_new_entry is true

Error message

invalid state, new_count = 0 and is_new_entry is true

What it means

In `apply_row`, when a bucket's new count reaches 0 the entry should be removed from state, so `is_new_entry` must be false. If a zero new count is paired with `is_new_entry = true`, the executor would insert a nonsensical zero-count row into the bucket state table; this internal invariant violation is bailed on instead.

Source

Thrown at src/stream/src/executor/approx_percentile/global_state.rs:222

            sign_datum.clone(),
            bucket_id_datum.clone(),
            Datum::from(ScalarImpl::Int64(old_count)),
        ];
        if new_count == 0 && !is_new_entry {
            self.bucket_state_table.delete(old_row);
        } else if new_count > 0 {
            let new_row = &[
                sign_datum,
                bucket_id_datum,
                Datum::from(ScalarImpl::Int64(new_count)),
            ];
            if is_new_entry {
                self.bucket_state_table.insert(new_row);
            } else {
                self.bucket_state_table.update(old_row, new_row);
            }
        } else {
            bail!("invalid state, new_count = 0 and is_new_entry is true")
        }

        Ok(())
    }

    pub async fn commit(&mut self, epoch: EpochPair) -> StreamExecutorResult<()> {
        // Commit row count state.
        let row_count_datum = Datum::from(ScalarImpl::Int64(self.row_count));
        let row_count_row = &[row_count_datum];
        let last_row_count_state = self.count_state_table.get_row(&[Datum::None; 0]).await?;
        match last_row_count_state {
            None => self.count_state_table.insert(row_count_row),
            Some(last_row_count_state) => self
                .count_state_table
                .update(last_row_count_state, row_count_row),
        }
        self.count_state_table
            .commit_assert_no_update_vnode_bitmap(epoch)

View on GitHub (pinned to 6469eb736d)

Solutions

1. Recreate the materialized view using approx_percentile to rebuild bucket state cleanly.
2. Check whether recovery/checkpoint was interrupted (previous crash) and consider re-ingesting the data.
3. Capture the input chunk and bucket id for a bug report; this indicates an internal invariant bug rather than a user error.
4. Upgrade RisingWave in case the bookkeeping bug is already fixed upstream.

When it happens

Trigger: Decrementing a bucket count to 0 while the entry is classified as new — a logic/state inconsistency, e.g. restored state missing an entry the code believes exists, or a bug in count bookkeeping.

Common situations: State restoration inconsistency after recovery, concurrency/state-write bugs, or corrupted bucket state tables causing count mismatch.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• snapshot backfill epoch set again: {} {} {}
• Invalid sign: {}
• Invalid row count state: {:?}
• invalid backfill state: row_count
• invalid backfill state: backfill_finished

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