risingwavelabs/risingwave · error

conflicting reschedule policies for fragments in the same no

Error message

conflicting reschedule policies for fragments in the same no-shuffle ensemble: {:?}

What it means

`reschedule_fragment_inplace` groups fragments into no-shuffle ensembles and requires every fragment in an ensemble to receive the same parallelism policy. When it collects the policies for an ensemble and finds more than one distinct value, it aborts with this error, because applying conflicting policies to fragments that must move together is undefined.

Source

Thrown at src/meta/src/stream/scale.rs:390

            let entry_fragment_ids = ensemble.entry_fragments().collect_vec();

            let desired_parallelism = match entry_fragment_ids
                .iter()
                .filter_map(|fragment_id| policy.get(fragment_id).cloned())
                .dedup()
                .collect_vec()
                .as_slice()
            {
                [] => {
                    bail_invalid_parameter!(
                        "none of the entry fragments {:?} were included in the reschedule request; \
                         provide at least one entry fragment id",
                        entry_fragment_ids
                    );
                }
                [parallelism] => parallelism.clone(),
                parallelisms => {
                    bail!(
                        "conflicting reschedule policies for fragments in the same no-shuffle ensemble: {:?}",
                        parallelisms
                    );
                }
            };

            let fragments = Fragment::find()
                .filter(fragment::Column::FragmentId.is_in(entry_fragment_ids))
                .all(&txn)
                .await?;

            debug_assert!(
                fragments
                    .iter()
                    .map(|fragment| fragment.parallelism.as_ref())
                    .all_equal(),
                "entry fragments in the same ensemble should share the same parallelism"
            );

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Inspect the logged `parallelisms` to see the conflicting values and identify the no-shuffle ensemble involved.
  2. Resubmit the reschedule specifying the same parallelism policy for all fragments in the ensemble.
  3. Simplify to a job-level parallelism reschedule if per-fragment control is not required.
  4. Use the ensemble's entry fragment id to set the policy once, which propagates to the whole ensemble.

Example fix

// before: conflicting per-fragment policies in one ensemble
ALTER TABLE t SET FRAGMENT 2 PARALLELISM = 4;
ALTER TABLE t SET FRAGMENT 3 PARALLELISM = 8; // same no-shuffle ensemble
// after
ALTER TABLE t SET FRAGMENT 2 PARALLELISM = 4;
ALTER TABLE t SET FRAGMENT 3 PARALLELISM = 4;
Defensive patterns

Strategy: validation

Validate before calling

// group fragments by ensemble and assert a single policy per ensemble before submitting
for (ensemble, policies) in policies_by_ensemble {
    if policies.iter().collect::<HashSet<_>>().len() > 1 {
        return Err(format!("ensemble {ensemble:?} has conflicting policies"));
    }
}

Try / catch

match reschedule_fragment(job_id, policies).await {
    Err(e) if e.to_string().contains("no-shuffle ensemble") => {
        // unify to one policy per ensemble and retry
        reschedule_fragment(job_id, unified_policies).await?
    }
    r => r?,
}

Prevention

When it happens

Trigger: Submitting a fragment-level reschedule (`ALTER ... SET FRAGMENT parallelism ...`) that specifies different fixed parallelism values for two or more fragments belonging to the same no-shuffle ensemble — e.g. fragment 2 -> fixed(4) and fragment 3 -> fixed(8) where both fragments are in one no-shuffle group.

Common situations: Operators tuning individual fragment parallelisms without knowing which fragments share a no-shuffle ensemble; scripted reschedules that iterate fragments and set different values; job topology changes altering ensemble membership between attempts.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors


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