risingwavelabs/risingwave · error

previous fragment info for {} not found

Error message

previous fragment info for {} not found

What it means

When checking whether a rendered (re-planned) fragment layout matches the current one, `rendered_layout_matches_current` looks up each rendered fragment id in the map of previous fragment states (`all_prev_fragments`). A rendered fragment with no corresponding previous fragment means the render produced fragments unknown to the current job state, so the function fails with this error. It guards the no-shuffle ensemble layout comparison during reschedule planning.

Source

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

/// this function sits on the reschedule path, which only re-renders fragments
/// that were loaded into the `RescheduleContext`. Fragment creation or deletion
/// is handled by separate DDL / recovery paths, not by reschedule, so fragments
/// outside the render set are irrelevant here. In other words, this is a subset
/// check over the rendered fragments, not a full bidirectional equality check.
pub(crate) fn rendered_layout_matches_current(
    render_result: &FragmentRenderMap,
    all_prev_fragments: &HashMap<FragmentId, &InflightFragmentInfo>,
) -> MetaResult<bool> {
    let all_rendered_fragments: HashMap<_, _> = render_result
        .values()
        .flat_map(|jobs| jobs.values())
        .flatten()
        .map(|(fragment_id, info)| (*fragment_id, info))
        .collect();

    for (fragment_id, rendered_fragment) in &all_rendered_fragments {
        let Some(prev_fragment) = all_prev_fragments.get(fragment_id).copied() else {
            return Err(MetaError::from(anyhow!(
                "previous fragment info for {} not found",
                fragment_id
            )));
        };

        let rendered_layout = build_normalized_fragment_layout(rendered_fragment);
        let current_layout = build_normalized_fragment_layout(prev_fragment);

        if rendered_layout != current_layout {
            return Ok(false);
        }
    }

    Ok(true)
}

pub struct ScaleController {
    pub metadata_manager: MetadataManager,

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Wait for the in-flight schema change/refresh to finish before issuing the reschedule, then retry.
  2. Rebuild the reschedule context so `all_prev_fragments` reflects the job's current fragment set.
  3. Verify the render result does not introduce new fragment ids for a layout-only reschedule check.
  4. If the fragment legitimately exists but is missing from the map, fix how previous fragments are collected (e.g. include fragments from all ensembles).
Defensive patterns

Strategy: validation

Validate before calling

// ensure every rendered fragment exists in the previous snapshot before rescheduling
let missing: Vec<_> = rendered.keys().filter(|id| !prev_fragments.contains_key(*id)).collect();
if !missing.is_empty() { return Err(format!("stale snapshot, missing fragments: {missing:?}")); }

Try / catch

match build_reschedule_from_context(ctx).await {
    Ok(plan) => apply(plan),
    Err(e) if e.to_string().contains("previous fragment info") => {
        // concurrent DDL detected: rebuild context and retry
        let ctx = rebuild_context().await?;
        build_reschedule_from_context(ctx).await?
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: Calling `build_reschedule_from_context` for a job whose render result contains fragment ids absent from `all_prev_fragments` — e.g. fragments added by a schema change/refresh that the previous-state snapshot does not yet include, or passing a stale/incomplete previous-fragment map.

Common situations: Rescheduling a job immediately after it entered a new phase (e.g. after a table refresh added fragments) while the reschedule context was built from an older snapshot; parallel schema change and reschedule operations racing.

Understand the failure class

Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.

Related errors


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