nautechsystems/nautilus_trader · error

Pool {pool_identifier} not found in cache

Error message

Pool {pool_identifier} not found in cache

What it means

After syncing events, `analyze_pool_with_client` fetches the pool from the data client's in-memory cache (`cache.get_pool`). If the pool is absent after registration+sync, the code raises this error because analysis cannot proceed without the pool object.

Source

Thrown at crates/cli/src/blockchain/analyze.rs:314

        // Sync once up to the final checkpoint, honoring reset/from_block. Each checkpoint then
        // bootstraps incrementally from the previous checkpoint's snapshot, so one pass produces
        // every snapshot.
        data_client
            .sync_pool_events(
                &dex_type,
                pool_identifier,
                from_block,
                Some(last_checkpoint),
                reset,
            )
            .await
            .map_err(|e| anyhow::anyhow!("Failed to sync pool events: {e}"))?;
    }

    let pool = data_client
        .cache
        .get_pool(&pool_identifier)
        .ok_or_else(|| anyhow::anyhow!("Pool {pool_identifier} not found in cache"))?
        .clone();

    let mut outcomes = Vec::with_capacity(checkpoints.len());
    let mut rpc_profiler = None;

    for checkpoint in checkpoints {
        log::info!("Profiling pool {pool_identifier} to checkpoint block {checkpoint}");
        let (profiler, already_valid) = bootstrap_profiler_for_checkpoint(
            data_client,
            &pool,
            checkpoint,
            snapshot_from_rpc,
            &mut rpc_profiler,
        )
        .await?;
        let snapshot = profiler.extract_snapshot()?;
        let snapshot_block_position = snapshot.block_position.clone();
        let positions = snapshot.positions.len();

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Check the pool address matches exactly (case/checksum) the one used during registration.
  2. Verify the pool exists on-chain for the configured chain and DEX type.
  3. Re-run with a fresh database/cache state (`--reset` on sync) to rebuild the pool entry.
  4. Inspect whether registration logged warnings indicating the pool failed to materialize.

Example fix

// before
--pool 0x123abc...  (lowercase)
// after
--pool 0x123AbC...  (checksummed as registered in cache)
Defensive patterns

Strategy: validation

Validate before calling

// after sync, before analysis:
if data_client.cache.get_pool(&pool_identifier).is_none() {
    anyhow::bail!("pool {} missing after sync; check address/DEX match", pool_identifier);
}

Prevention

When it happens

Trigger: Running pool analysis where, despite registration succeeding, `cache.get_pool(&pool_identifier)` returns `None` — registration partially completed, sync produced no state that materializes the pool, or the identifier string mismatches the checksummed form used as the cache key.

Common situations: Passing a lowercase pool address while the cache stores the checksummed one (or vice versa); a sync that silently stored no pool events; analyzing a pool contract that isn't actually the given DEX type.

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/a9e88d168a5faac1. Report an issue: GitHub.