nautechsystems/nautilus_trader · error

Catalog {catalog_name} disappeared between intervals query a

Error message

Catalog {catalog_name} disappeared between intervals query and read

What it means

While dispatching a date-range request leg, query_catalog_leg re-fetches the Parquet catalog from self.catalogs by name after the initial intervals query, and the entry is gone. The engine treats catalog removal between the two lookups as an unrecoverable inconsistency and raises this error rather than returning partial data.

Source

Thrown at crates/data/src/engine/streaming.rs:391

    fn abort_request_pipeline(&mut self, parent_id: UUID4) {
        self.request_pipeline_n_components.remove(&parent_id);
        self.request_pipeline_parent_request.remove(&parent_id);
        self.request_pipeline_responses.remove(&parent_id);
        self.request_pipeline_parent_request_id
            .retain(|_, p_id| *p_id != parent_id);
    }

    fn query_catalog_leg(
        &mut self,
        leg: &RequestCommand,
        catalog_name: Ustr,
        start_ns: UnixNanos,
        end_ns: UnixNanos,
        used_client_id: Option<ClientId>,
        ts_init: UnixNanos,
    ) -> anyhow::Result<DataResponse> {
        let catalog = self.catalogs.get_mut(&catalog_name).ok_or_else(|| {
            anyhow::anyhow!("Catalog {catalog_name} disappeared between intervals query and read")
        })?;

        match leg {
            RequestCommand::Quotes(cmd) => {
                let data: Vec<QuoteTick> = catalog.quote_ticks(
                    Some(vec![cmd.instrument_id.to_string()]),
                    Some(start_ns),
                    Some(end_ns),
                )?;
                Ok(build_quotes_catalog_response(
                    cmd,
                    data,
                    start_ns,
                    end_ns,
                    used_client_id,
                    ts_init,
                ))
            }

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Confirm the catalog name passed to the date-range request exactly matches a registered catalog.
  2. Check for concurrent code paths that deregister or close catalogs while requests are in flight; serialize or lock catalog lifecycle changes.
  3. Re-register the catalog (or re-run registration) before re-issuing the request.
  4. Capture/hold the catalog reference across the whole request instead of re-fetching by name at read time.
Defensive patterns

Strategy: validation

Validate before calling

// confirm the catalog is registered before dispatching a date-range request
if !engine.catalogs.contains_key(&catalog_name) {
    return Err(anyhow::anyhow!("catalog {catalog_name} not registered"));
}

Try / catch

match result {
    Err(e) if e.to_string().contains("disappeared between intervals query and read") => {
        // re-register catalog and retry the request once
    }
    other => other?,
}

Prevention

When it happens

Trigger: Calling query_catalog_leg (via dispatch_date_range_request) with a catalog_name that was present during the intervals query but has been removed from self.catalogs (or mutated out) before the get_mut at read time.

Common situations: A concurrent write/registration operation removed or replaced the catalog mid-request; a typo in the catalog name means only the earlier lookup path resolved it (e.g. case/alias handling); the catalog was closed and deregistered while a long-running date-range dispatch was in flight.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/514c68cca296d12d. Report an issue: GitHub.