risingwavelabs/risingwave · error · MetaError
table_fragment does not exist: id={0}
Error message
table_fragment does not exist: id={0} What it means
The meta node could not find a streaming table fragment with the given FragmentId. Fragments are the distributed execution units of a streaming job; this error means the fragment manager has no record of that id.
Source
Thrown at src/meta/src/error.rs:80
#[backtrace]
RpcError,
),
#[error("{0}")]
PermissionDenied(String),
#[error("Invalid worker: {0}, {1}")]
InvalidWorker(WorkerId, String),
#[error("Invalid parameter: {0}")]
InvalidParameter(#[message] String),
// Used for catalog errors.
#[error("{0} id not found: {1}")]
#[construct(skip)]
CatalogIdNotFound(&'static str, String),
#[error("table_fragment does not exist: id={0}")]
FragmentNotFound(FragmentId),
#[error("{0} named {1} already exists{under_creation}", under_creation = (.2).map(|_| " and is still being created").unwrap_or(""))]
Duplicated(
&'static str,
String,
// if under creation, take streaming job id, otherwise None
Option<JobId>,
),
#[error("Service unavailable: {0}")]
Unavailable(#[message] String),
#[error("Election failed: {0}")]
Election(#[source] BoxedError),
#[error("Cancelled: {0}")]
Cancelled(String),View on GitHub (pinned to 6469eb736d)
Solutions
- Verify the owning streaming job still exists (`SHOW MATERIALIZED VIEWS` / `SHOW SOURCES`) and use its current fragments.
- Re-fetch fragment ids via risectl meta list-fragments instead of cached values.
- If the job was dropped, the fragments are gone by design; stop using those ids.
- After cluster restore/migration, re-query fragment mappings.
Defensive patterns
Strategy: try-catch
Validate before calling
let fragments = meta_client.list_fragments(job_id).await?; assert!(fragments.iter().any(|f| f.fragment_id == fragment_id));
Try / catch
match meta_result {
Err(MetaError::FragmentNotFound(id)) => { /* refresh fragment list or stop using dropped job's fragments */ }
other => other?,
} Prevention
- Confirm the owning streaming job still exists before fragment operations.
- Re-list fragments instead of reusing cached fragment ids.
- Avoid inspecting fragments of jobs that may be dropped concurrently.
When it happens
Trigger: Querying or modifying fragment state (scaling APIs, fragment backfill, fragment detail lookup) with a fragment id belonging to a dropped streaming job or an id from another cluster.
Common situations: Stream job dropped concurrently while its fragments are being inspected, stale fragment ids cached in tooling after recovery/migration, misapplied id mapping after cluster restore.
Understand the failure class
Background: Record Not Found Errors: "not found", RecordNotFound, and "was not found" — what they mean and how to fix them — this error's family across 28 libraries.
Related errors
- database {} not found when resolving reschedule intent
- cannot find subscription with id {}
- Failed to retrieve fragment description: fragment {} (job_id
- job {} not found in database
- fragment {} not found in shared actor info
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/7455fb6173f4fd9a.
Report an issue: GitHub.