risingwavelabs/risingwave · error

updating vnode bitmap in place is not supported

Error message

updating vnode bitmap in place is not supported

What it means

When a stream executor receives a configuration-change (mutation) message, the code checks whether that message carries a vnode bitmap update for the actor. In-place updating of the vnode bitmap is not supported by this path, so if `as_update_vnode_bitmap` finds one, the executor rejects it with this error instead of silently mis-applying a parallelism change.

Solutions

1. Avoid rescaling the affected materialization/job while this executor type is in the topology, or recreate it under the desired parallelism
2. Upgrade RisingWave: newer versions broaden which executors handle vnode bitmap updates
3. If it reproduces on a normal rescale, file an issue with the job definition and the actor list; the meta service should not route bitmap updates to this executor

// Before rescaling, confirm no executors reject in-place vnode updates
let change_ok = plan_mutations(&job).all(|m| !requires_vnode_bitmap_update_in_place(&m));

match rescale_result {
    Err(e) if e.to_string().contains("updating vnode bitmap in place is not supported") => {
        // Fall back to recreating the job at the new parallelism
        recreate_job_with_parallelism(job_id, new_parallelism);
    }
    other => other?,
}

When it happens

Trigger: A mutation message containing `UpdateVnodeBitmap` is dispatched to an executor that calls `assume_no_update_vnode_bitmap`, i.e. a parallelism/rescale operation whose vnode-bitmap change reaches an executor that cannot apply it in place.

Common situations: Rescaling (ALTER ... SET PARALLELISM) a streaming job whose topology includes executors that only support this operation via the barrier-based no-update contract; bugs in the meta service's mutation routing.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Actor exited unexpectedly
• Array error
• below watermark check condition eval must return bool array
• Chunk operation error
• clean watermark column index

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

Appendix: source

Thrown at src/stream/src/executor/mod.rs:682

    /// Returns the new vnode bitmap if this barrier is to update the vnode bitmap for the actor
    /// with `actor_id`.
    ///
    /// Actually, this vnode bitmap update is only useful for the record accessing validation for
    /// distributed executors, since the read/write pattern will never be across multiple vnodes.
    pub fn as_update_vnode_bitmap(&self, actor_id: ActorId) -> Option<Arc<Bitmap>> {
        self.mutation
            .as_deref()
            .and_then(|mutation| match mutation {
                Mutation::Update(UpdateMutation { vnode_bitmaps, .. }) => {
                    vnode_bitmaps.get(&actor_id).cloned()
                }
                _ => None,
            })
    }

    pub fn assume_no_update_vnode_bitmap(&self, actor_id: ActorId) -> StreamExecutorResult<()> {
        if self.as_update_vnode_bitmap(actor_id).is_some() {
            return Err(anyhow!("updating vnode bitmap in place is not supported").into());
        }
        Ok(())
    }

    pub fn as_sink_schema_change(&self, sink_id: SinkId) -> Option<PbSinkSchemaChange> {
        self.mutation
            .as_deref()
            .and_then(|mutation| match mutation {
                Mutation::Update(UpdateMutation {
                    sink_schema_change, ..
                }) => sink_schema_change.get(&sink_id).cloned(),
                _ => None,
            })
    }

    pub fn should_flush_sink_log_store(&self, sink_id: SinkId) -> bool {
        self.mutation
            .as_deref()

View on GitHub (pinned to 6469eb736d)