nautechsystems/nautilus_trader · error · anyhow::Error

Execution intent {intent_id} was not found

Error message

Execution intent {intent_id} was not found

What it means

Thrown when the FOR UPDATE lookup in record_execution_status finds no execution_intent row with the given id. The id must originate from the ExecutionIntentRow returned by reserve_execution_intent; passing a v1 execution_transaction hash, a hash-table row id, an invented id, or running against a database that was reset while the process kept in-memory state all produce this.

Source

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

            format!(
                "Execution gas used {} exceeds PostgreSQL BIGINT",
                gas_used.unwrap_or_default()
            )
        })?;
        let mut transaction = self
            .pool
            .begin()
            .await
            .map_err(|e| anyhow::anyhow!("Failed to start execution status transition: {e}"))?;
        let (current_status, fill_emitted, terminal_emitted) =
            sqlx::query_as::<_, (String, bool, bool)>(
            "SELECT status, fill_emitted, terminal_emitted FROM execution_intent WHERE id = $1 FOR UPDATE",
        )
        .bind(intent_id)
        .fetch_optional(&mut *transaction)
        .await
        .map_err(|e| anyhow::anyhow!("Failed to lock execution intent {intent_id}: {e}"))?
        .ok_or_else(|| anyhow::anyhow!("Execution intent {intent_id} was not found"))?;
        anyhow::ensure!(
            execution_transition_allowed(&current_status, status),
            "Invalid execution transition for intent {intent_id}: {current_status} -> {}",
            status.as_str()
        );

        let active = match status {
            TransactionStatus::Finalized | TransactionStatus::Reverted => {
                !fill_emitted && !terminal_emitted
            }
            TransactionStatus::Recoverable => false,
            _ => true,
        };
        let hash_result = sqlx::query(
            "
            UPDATE execution_transaction_hash
            SET status = $3,
                block_number = COALESCE($4, block_number),

View on GitHub (pinned to 2114cf6f76)

Solutions

  1. Trace the value back to the ExecutionIntentRow returned by reserve_execution_intent - only that id is valid
  2. When starting from a transaction hash, resolve intent_id via execution_transaction_hash first and use that
  3. After any database reset or restore, rebuild in-memory state before recording observations

Example fix

// before: recording with an id that is not the intent id
db.record_execution_status(hash_row.id, &tx_hash, status, ...).await?;

// after: resolve the owning intent first
let intent_id: i64 = sqlx::query_scalar(
    "SELECT intent_id FROM execution_transaction_hash WHERE chain_id = $1 AND transaction_hash = $2",
)
.bind(chain_id)
.bind(&tx_hash)
.fetch_one(&pool)
.await?;
db.record_execution_status(intent_id, &tx_hash, status, ...).await?;
Defensive patterns

Strategy: validation

Validate before calling

// Confirm the intent exists before recording an observation
let exists: bool = sqlx::query_scalar("SELECT EXISTS (SELECT 1 FROM execution_intent WHERE id = $1)")
    .bind(intent_id)
    .fetch_one(&pool)
    .await?;
if !exists { /* resolve via execution_transaction_hash or re-reserve */ }

Type guard

fn is_intent_id(id: i64, reserved: &ExecutionIntentRow) -> bool {
    id == reserved.id
}

Try / catch

match db.record_execution_status(intent_id, &tx_hash, status, block, hash, success, gas, price).await {
    Err(e) if e.to_string().contains("was not found") => {
        // resolve the correct intent_id from execution_transaction_hash, or drop stale in-memory state
    }
    other => other?,
}

Prevention

When it happens

Trigger: Calling record_execution_status with a transaction hash or execution_transaction_hash.id instead of the intent id; the schema was dropped and recreated between reserve and record; recording an observation before the reservation committed.

Common situations: Mixed-version code paths confusing v1 and v2 identifiers; test environments recreating the cache schema; database restored from a snapshot while workers kept state.

Related errors

AI-assisted analysis of nautechsystems/nautilus_trader@2114cf6f76 (2026-08-21). Data as JSON: /api/errors/c2b851b90ea43136. Report an issue: GitHub.