risingwavelabs/risingwave · error · MetaError
database {} not found when resolving reschedule intent
Error message
database {} not found when resolving reschedule intent What it means
resolve_reschedule_intent needs the in-flight database info to build a reschedule plan from a barrier context. If the catalog has no record of the barrier's database_id, it fails with `database <id> not found when resolving reschedule intent`, refusing to construct a plan against unknown database state.
Source
Thrown at src/meta/src/barrier/worker.rs:219
reschedule_plan: Some(reschedule_plan),
},
notifier,
));
return Ok(Some(new_barrier));
}
let span = tracing::info_span!(
"resolve_reschedule_intent",
database_id = %new_barrier.database_id
);
let reschedule_plan = {
let _guard = span.enter();
build_reschedule_from_context(
&env,
worker_nodes,
new_barrier.database_id,
context,
database_info.ok_or_else(|| {
anyhow!(
"database {} not found when resolving reschedule intent",
new_barrier.database_id
)
})?,
)
};
match reschedule_plan {
Ok(Some(reschedule_plan)) => {
new_barrier.command = Some((
Command::RescheduleIntent {
context: RescheduleContext::empty(),
reschedule_plan: Some(reschedule_plan),
},
notifier,
));
Ok(Some(new_barrier))
}
Ok(None) => {View on GitHub (pinned to 6469eb736d)
Solutions
- Verify the database exists: `SHOW DATABASES;` — recreate it if it was dropped unintentionally.
- Restart the client/session so it resolves current catalog state instead of a stale database id.
- If this follows a DROP, drain or restart the affected sessions; recovery will clear stale queued requests.
- If the database exists but lookup fails, run recovery to rebuild in-flight database info from the catalog.
Example fix
// before: using a cached database id across a drop
let db_id = session.cached_database_id();
worker.resolve_reschedule_intent(barrier_with(db_id)).await?;
// after: re-resolve the id from the catalog first
let db_id = catalog.lookup_database_id(session.database_name()).await
.context("database no longer exists; recreate it")?; Defensive patterns
Strategy: validation
Validate before calling
-- confirm the database still exists before relying on a cached id SHOW DATABASES; -- or in code: catalog.lookup_database_id(name).await? before issuing requests
Type guard
fn database_known(info: &Option<InflightDatabaseInfo>) -> bool {
info.is_some()
} Try / catch
match err {
e if e.to_string().contains("not found when resolving reschedule intent") => {
// refresh session catalog state, reconnect, or recreate the database
}
e => return Err(e.into()),
} Prevention
- Avoid long-lived sessions that cache database ids across DDL.
- Re-resolve database names to ids after any DROP/CREATE cycle.
- Run recovery after catalog-affecting failures so in-flight info matches the catalog.
When it happens
Trigger: A BarrierManagerRequest carrying a database_id arrives while that database no longer exists in the catalog (dropped concurrently, or catalog state lagging), so `database_info` lookup returns None; the test test_reschedule_intent_without_workers_notifies_start_failed exercises this path.
Common situations: Race between `DROP DATABASE` and in-flight barrier/reschedule requests; stale client sessions referencing a deleted database; catalog recovery leaving the worker with pre-drop requests queued.
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
- cannot find subscription with id {}
- job {} not found in database
- {0} id not found: {1}
- mv not found
- {object_type} not found: {name}
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/ff9540aeb5c25c96.
Report an issue: GitHub.