nautechsystems/nautilus_trader · error · anyhow::Error

Failed to load latest valid pool snapshot: {e}

Error message

Failed to load latest valid pool snapshot: {e}

What it means

This error wraps any SQLx failure that occurs while running the query that fetches the most recent valid pool snapshot row from the PostgreSQL snapshot store (`fetch_optional`). The library converts the underlying driver error into an `anyhow` error with this message so callers get pool-snapshot context instead of a bare database error. It means the SELECT itself failed — the row was not simply missing.

Source

Thrown at crates/adapters/blockchain/src/cache/database.rs:2419

                COALESCE(
                    (SELECT timestamp::TEXT FROM block WHERE block.chain_id = pool_snapshot.chain_id AND block.number = pool_snapshot.block),
                    (SELECT timestamp::TEXT FROM pool_event_block WHERE pool_event_block.chain_id = pool_snapshot.chain_id AND pool_event_block.number = pool_snapshot.block)
                ) as block_timestamp
            FROM pool_snapshot
            WHERE chain_id = $1 AND pool_identifier = $2
                AND ($3::BIGINT IS NULL OR block <= $3)
                AND ($4 OR validation_state <> 'invalid')
            ORDER BY block DESC, transaction_index DESC, log_index DESC
            LIMIT 1
            ",
        )
        .bind(chain_id as i32)
        .bind(pool_identifier.as_ref())
        .bind(max_block.map(|b| b as i64))
        .bind(allow_invalid)
        .fetch_optional(&self.pool)
        .await
        .map_err(|e| anyhow::anyhow!("Failed to load latest valid pool snapshot: {e}"))?;

        if let Some(row) = result {
            // Parse snapshot state
            let block: i64 = row.get("block");
            let transaction_index: i32 = row.get("transaction_index");
            let log_index: i32 = row.get("log_index");
            let transaction_hash: String = row.get("transaction_hash");
            let observed_block_hash = row.try_get::<Option<String>, _>("block_hash")?;
            let block =
                u64::try_from(block).with_context(|| "Pool snapshot block number is negative")?;
            let transaction_index = u32::try_from(transaction_index)
                .with_context(|| "Pool snapshot transaction index is negative")?;
            let log_index =
                u32::try_from(log_index).with_context(|| "Pool snapshot log index is negative")?;
            let block_hash = if transaction_index == BLOCK_SCOPED_SNAPSHOT_INDEX
                && log_index == BLOCK_SCOPED_SNAPSHOT_INDEX
            {
                Some(transaction_hash.clone())

View on GitHub (pinned to 18893faf8b)

Solutions

1. Verify the database is reachable and credentials in the connection URL are correct (psql with the same URL).
2. Confirm migrations have been applied and the pool-snapshot table/columns match the adapter's expected schema; run migrations if not.
3. Check Postgres logs for the underlying error (auth failure, too many connections, lock timeout).
4. Restart the adapter or recycle the sqlx pool to clear stale connections after a DB restart.
5. Inspect the chained source error (`{e}`) in the message for the exact driver-level cause.

Example fix

// before: retry on any error
let snap = cache.load_latest_valid_snapshot(...).await?;
// after: check DB availability first and surface the inner error
let snap = cache.load_latest_valid_snapshot(...).await
    .map_err(|e| { tracing::error!(cause = ?e.source(), "snapshot load failed"); e })?;

let ok = sqlx::any::AnyPool::connect(&url).await.is_ok(); // or run a trivial SELECT 1 against the pool before loading
assert!(ok, "database unreachable before snapshot load");

match cache.load_latest_valid_snapshot(...).await {
    Ok(snap) => snap,
    Err(e) => { tracing::error!(cause = ?e.source(), "snapshot load failed"); return Err(e); }
}

When it happens

Trigger: Calling the database cache's latest-snapshot loader when the Postgres connection is down, the `pool_snapshots` table/schema is missing or was migrated (column renames break the bound columns `chain_id`, `pool_identifier`, `max_block`, `allow_invalid`), credentials are wrong, or the connection pool has timed out / hit max connections.

Common situations: Starting the adapter against a database that has not had migrations applied; Docker Postgres container stopped; stale pooled connections after a database restart/failover; schema drift after upgrading the adapter version; wrong DATABASE_URL in the environment.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

• Failed to seed chain table: {e}
• Failed to call create_block_partition for chain {}: {e}
• Failed to call create_token_partition for chain {}: {e}
• Failed to get block info for chain {}: {}
• Failed to insert into block table: {e}

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