Released terminal intent status conflicts with its verified

Error message

Released terminal intent status conflicts with its verified receipt

What it means

When releasing a terminal intent during migration, the client derives the expected status (Finalized or Reverted) from the verified receipt and ensures the persisted intent status matches it. This prevents publishing a released intent whose recorded status disagrees with the on-chain outcome, which would corrupt downstream state machines.

Source

Thrown at crates/adapters/blockchain/src/execution/client.rs:5583

                    self.chain.chain_id,
                    &self
                        .config
                        .verification
                        .as_ref()
                        .expect("verification config validated")
                        .deployment_manifest,
                    trace_purpose,
                )
                .await?,
            );
            let terminal_status = if receipt.status {
                TransactionStatus::Finalized
            } else {
                TransactionStatus::Reverted
            };

            if !intent.active {
                anyhow::ensure!(
                    intent.status == terminal_status.as_str(),
                    "Released terminal intent status conflicts with its verified receipt"
                );
            }
            records.push(ExecutionVerificationMigrationRecord {
                intent_id: intent.id,
                nonce: Some(nonce),
                transaction_hash: Some(current.transaction_hash.clone()),
                terminal_status: Some(terminal_status),
                block_number: Some(receipt.block_number),
                block_hash: Some(receipt.block_hash.to_string()),
                receipt_success: Some(receipt.status),
                gas_used: Some(receipt.gas_used),
                effective_gas_price: Some(receipt.effective_gas_price.to_string()),
                recover_prepared: false,
                decisions,
            });
        }

View on GitHub (pinned to 18893faf8b)

Solutions

Inspect the durable intent record and update its status to match the verified receipt outcome (finalized/reverted)
Re-derive intent statuses from receipts via the migration repair path instead of trusting stored status
Check for schema/version drift between the writer that stored the status and this migration code
Exclude or quarantine the conflicting intent so it is re-processed after the migration completes

Example fix

// before
intent.status = "success"
// after (must equal the receipt-derived terminal status)
intent.status = TransactionStatus::Finalized.as_str() // "finalized"

Defensive patterns

Strategy: validation

Validate before calling

// before releasing, confirm status matches the receipt-derived terminal status
let expected = if receipt_success { "finalized" } else { "reverted" };
assert_eq!(intent.status, expected, "intent status must match verified receipt");

Type guard

fn is_consistent_terminal_intent(intent: &Intent, receipt: &Receipt) -> bool {
    !intent.active && intent.status == terminal_status_from(receipt)
}

Try / catch

match release_intent(&intent).await {
    Err(e) if e.to_string().contains("status conflicts with its verified receipt") => {
        reconcile_intent_status_from_receipt(&intent.id).await?; // repair and retry
    }
    Err(e) => return Err(e),
    Ok(_) => Ok(()),
}

Prevention

Always derive intent status from the receipt in the same transaction that stores the receipt
Keep status enum strings consistent across client versions (avoid ad-hoc strings like "success")
Handle crashes between receipt confirmation and status update with a reconciliation pass
Validate persisted intents at startup before releasing

When it happens

Trigger: Migrating/releasing an inactive (terminal) intent whose stored status string is not exactly "finalized" or "reverted" as implied by its verified receipt's execution outcome.

Common situations: Statuses written by an older client version using different status strings; a crash between receipt confirmation and status update; manual edits or partial writes to the durable intent store; deserialized records from another chain where the outcome differed.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

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