risingwavelabs/risingwave · error

previous fragment info for {fragment_id} not found

Error message

previous fragment info for {fragment_id} not found

What it means

`build_reschedule_commands` first collects all fragment ids related to the reschedule (from the diff and rendered plan) and asserts each one exists in `all_prev_fragments`, the snapshot of the job's current fragments. If any related fragment id is absent from that snapshot, planning cannot proceed and this error is returned. It ensures the reschedule plan is grounded in the job's existing fragment state.

Source

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

        .flatten()
        .map(|(fragment_id, _)| *fragment_id)
        .collect_vec();

    let all_related_fragment_ids: HashSet<_> = fragment_ids
        .iter()
        .copied()
        .chain(all_upstream_fragments.values().flatten().map(|(id, _)| *id))
        .chain(
            all_downstream_fragments
                .values()
                .flatten()
                .map(|(id, _)| *id),
        )
        .collect();

    for fragment_id in all_related_fragment_ids {
        if !all_prev_fragments.contains_key(&fragment_id) {
            return Err(MetaError::from(anyhow!(
                "previous fragment info for {fragment_id} not found"
            )));
        }
    }

    let all_rendered_fragments: HashMap<_, _> = render_result
        .values()
        .flat_map(|jobs| jobs.values())
        .flatten()
        .map(|(fragment_id, info)| (*fragment_id, info))
        .collect();

    let mut commands = HashMap::new();

    for (database_id, jobs) in &render_result {
        let mut all_fragment_actors = HashMap::new();
        let mut reschedules = HashMap::new();

View on GitHub (pinned to 6469eb736d)

Solutions

1. Retry the reschedule after any concurrent DDL (schema change, refresh, creation) on the job completes.
2. Rebuild the reschedule context so `all_prev_fragments` includes all related fragments, including downstream/external ones.
3. From the logged fragment_id, check which relation/graph edge references it and ensure that fragment is collected into the snapshot.
4. If a recently created fragment is missing, verify the snapshot is fetched after the fragment becomes visible in the meta state.

// verify all related fragment ids exist in the snapshot before planning
let missing: Vec<_> = related_fragment_ids
    .iter()
    .filter(|id| !prev_fragments.contains_key(*id))
    .collect();
if !missing.is_empty() { return Err(format!("stale context, missing: {missing:?}")); }

match build_reschedule_from_context(ctx).await {
    Err(e) if e.to_string().contains("not found") => {
        let ctx = refresh_context_after_ddl_settles().await?;
        build_reschedule_from_context(ctx).await
    }
    r => r,
}

When it happens

Trigger: Calling `build_reschedule_from_context` where the diff/render step references a fragment id (e.g. a downstream or upstream fragment discovered through the dependency graph) that is not present in the previous-fragment snapshot passed into the context.

Common situations: Rescheduling while the fragment graph is mid-update (e.g. a parallel schema change added/removed fragments); building the context from a stale or partial snapshot that omits external/downstream fragments; job topology changed since the snapshot was taken.

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

• previous fragment info for {} not found
• fragment {} not found in previous state
• conflicting reschedule policies for fragments in the same no
• BUG: Worker not found for new actor {}
• reschedule failed

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