risingwavelabs/risingwave · error

entry fragments {:?} have inconsistent parallelism settings

Error message

entry fragments {:?} have inconsistent parallelism settings

What it means

render_actors_with_allocator renders actors for one no-shuffle ensemble at a time. All entry fragments in an ensemble must share the same parallelism; Itertools::exactly_one over their parallelism values fails otherwise, producing this error with the offending entry fragment IDs.

Source

Thrown at src/meta/src/controller/scale.rs:962

        entries,
        components,
    } in ensembles
    {
        tracing::debug!("rendering ensemble entries {:?}", entries);

        let entry_fragments = entries
            .iter()
            .map(|fragment_id| fragment_lookup.get(fragment_id).unwrap())
            .collect_vec();

        let entry_fragment_parallelism = Itertools::exactly_one(
            entry_fragments
                .iter()
                .map(|fragment| fragment.parallelism.clone())
                .dedup(),
        )
        .map_err(|_| {
            anyhow!(
                "entry fragments {:?} have inconsistent parallelism settings",
                entries.iter().copied().collect_vec()
            )
        })?;

        let (job_id, distribution_type, vnode_count) = Itertools::exactly_one(
            entry_fragments
                .iter()
                .map(|f| (f.job_id, f.distribution_type, f.vnode_count))
                .dedup(),
        )
        .map_err(|_| anyhow!("Multiple jobs found in no-shuffle ensemble"))?;

        let job = job_map
            .get(&job_id)
            .ok_or_else(|| anyhow!("streaming job {job_id} not found"))?;

        let database_resource_group = streaming_job_databases

View on GitHub (pinned to 6469eb736d)

Solutions

1. Align parallelism of the listed entry fragments in the catalog so the ensemble is consistent.
2. Re-run the rescale/replace from a fresh loaded context so all fragments of the ensemble get the same target parallelism.
3. Check for interrupted ALTER ... SET PARALLELISM operations and complete or roll them back.
4. File a bug with fragment IDs from the message if the state cannot be explained by in-flight DDL.

let pars: HashSet<_> = entry_fragments.iter().map(|f| f.parallelism.clone()).collect();
if pars.len() != 1 {
    bail!("entry fragments {:?} differ in parallelism: {:?}", entries, pars);
}

match render_actors_with_allocator(&ctx, ...) {
    Err(e) if e.to_string().contains("inconsistent parallelism") => {
        // reload context and retry once after DDL settles
        reload_and_retry().await
    }
    r => r,
}

When it happens

Trigger: An ensemble mixes entry fragments with different parallelism settings — e.g. fragments produced/modified by different job versions or a rescale that changed parallelism for some fragments of the ensemble but not others.

Common situations: Partial rescale/alter operations interrupted midway; legacy jobs upgraded across versions where parallelism persisted per-fragment inconsistently; hand-edited catalog rows.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

• missing source id in source fragment {}
• fragments {:?} not found
• Multiple jobs found in no-shuffle ensemble
• streaming job {job_id} not found
• streaming job {job_id} not found in streaming_job_databases

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