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
- Inspect the logged `parallelisms` to see the conflicting values and identify the no-shuffle ensemble involved.
- Resubmit the reschedule specifying the same parallelism policy for all fragments in the ensemble.
- Simplify to a job-level parallelism reschedule if per-fragment control is not required.
- 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
- Learn which fragments share a no-shuffle ensemble before setting per-fragment parallelism.
- Set the policy via the ensemble's entry fragment id instead of individual fragments.
- Prefer job-level parallelism reschedule when uniform scaling is acceptable.
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
- previous fragment info for {} not found
- previous fragment info for {fragment_id} not found
- fragment {} not found in previous state
- reschedule failed
- duplicate worker id {worker_id} in plan, prev {worker_id} ->
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/cadc4dcd56c70d33.
Report an issue: GitHub.