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
- Check database connectivity and retry the whole batch operation; the transaction is atomic so a retry is safe
- Run pending migrations so execution_verification_decision exists
- Look at the inner `{e}` source for the underlying sqlx/Postgres error code
- 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
- Keep migrations current with the binary version
- Monitor pool health and connection errors
- Keep the whole batch in one transaction (already done) so retries are safe
- Log the inner source chain ({e:?}) to distinguish transient vs schema errors
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
- Failed to load block timestamps: {e}
- Failed to load active execution intent: {e}
- Failed to seed chain table: {e}
- Failed to call create_block_partition for chain {}: {e}
- Failed to call create_token_partition for chain {}: {e}
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/53f0a6a3c58266a3.
Report an issue: GitHub.