nautechsystems/nautilus_trader · error

Failed to number verified action evidence: {e}

Error message

Failed to number verified action evidence: {e}

What it means

Inside record_execution_verification_batch, the code counts existing evidence rows for the intent/decision_class to number the batch (the `attempt` used in transition_key). If the COUNT(*) query fails at the database level, it is wrapped as this error.

Source

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

        .await
        .map_err(|e| anyhow::anyhow!("Failed to lock intent for verified action: {e}"))?
        .ok_or_else(|| anyhow::anyhow!("Active verified-action intent was not found"))?;
        anyhow::ensure!(
            intent_nonce == Some(nonce),
            "Verified action nonce does not match the active intent"
        );
        let attempt = sqlx::query_scalar::<_, i64>(
            "
            SELECT COUNT(*)
            FROM execution_verification_decision
            WHERE intent_id = $1 AND decision_class = $2
            ",
        )
        .bind(batch.intent_id)
        .bind(batch.decision_class)
        .fetch_one(&mut *transaction)
        .await
        .map_err(|e| anyhow::anyhow!("Failed to number verified action evidence: {e}"))?;

        for (index, decision) in batch.decisions.iter().enumerate() {
            let height_start = decision
                .height_start
                .map(i64::try_from)
                .transpose()
                .context("Verification height exceeds PostgreSQL BIGINT")?;
            let height_end = decision
                .height_end
                .map(i64::try_from)
                .transpose()
                .context("Verification height exceeds PostgreSQL BIGINT")?;
            let transition_key = format!(
                "{}:{}:{attempt}:{}:{index}",
                batch.decision_class, batch.intent_id, decision.read_class
            );
            sqlx::query(
                "

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Check database connectivity and retry the whole batch operation; the transaction is atomic so a retry is safe
  2. Run pending migrations so execution_verification_decision exists
  3. Look at the inner `{e}` source for the underlying sqlx/Postgres error code
  4. Ensure no earlier statement in the transaction has aborted it before this query
Defensive patterns

Strategy: retry

Validate before calling

// verify schema exists before calling
sqlx::query("SELECT 1 FROM execution_verification_decision LIMIT 1")
    .fetch_optional(&pool).await?
    .ok_or_else(|| anyhow::anyhow!("migrations missing"))?;

Try / catch

if let Err(e) = db.record_execution_verification_batch(&batch).await {
    if e.to_string().contains("Failed to number verified action evidence") {
        // transient DB issue: backoff and retry whole batch (transaction is atomic)
        tokio::time::sleep(Duration::from_secs(1)).await;
        return retry(batch).await;
    }
    return Err(e);
}

Prevention

When it happens

Trigger: The SELECT COUNT(*) FROM execution_verification_decision WHERE intent_id = $1 AND decision_class = $2 query fails: connection drop, transaction already aborted by a prior error, statement timeout, or the table missing (schema not migrated).

Common situations: Postgres connection pool exhaustion or network blip mid-transaction; running against a database missing recent migrations; a previous statement in the transaction aborted it so subsequent queries fail.

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


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