nautechsystems/nautilus_trader · error
Persisted transaction row references intent {}, expected {}
Error message
Persisted transaction row references intent {}, expected {} What it means
A persisted transaction row (transaction hash record) references a different intent id than the active intent being reconciled. This is an internal consistency check on the database join between intents and their transactions.
Source
Thrown at crates/adapters/blockchain/src/execution/client.rs:1195
let hashes = database.get_execution_transaction_hashes(intent.id).await?;
let current = current_execution_hash(intent.id, &hashes)?;
let tx_hash = B256::from_str(¤t.transaction_hash).with_context(|| {
format!(
"Execution intent {} has invalid transaction hash {}",
intent.id, current.transaction_hash
)
})?;
let policy = PayloadPolicy {
chain_id: self.chain.chain_id,
signer: self.wallet_address,
gas_limit: self.config.gas_limit,
max_fee_per_gas: self.config.max_fee_per_gas_wei,
};
let mut authenticated_payloads = HashMap::new();
let mut current_payload = None;
for hash in &hashes {
anyhow::ensure!(
hash.intent_id == intent.id,
"Persisted transaction row references intent {}, expected {}",
hash.intent_id,
intent.id
);
anyhow::ensure!(
hash.chain_id == self.chain.chain_id,
"Persisted transaction row chain ID {} does not match configured chain ID {}",
hash.chain_id,
self.chain.chain_id
);
if !hash.payload_expected {
anyhow::ensure!(
hash.raw_transaction.is_none() && hash.sealed_transaction.is_none(),
"Replacement transaction {} unexpectedly retains signed bytes",
hash.transaction_hash
);View on GitHub (pinned to 18893faf8b)
Solutions
- Inspect the execution transactions table and fix or remove rows whose intent_id is inconsistent
- Re-derive transactions for the intent from a clean state (let the client re-sign)
- Audit the code path that inserts transaction rows to ensure intent_id is always set from the active intent
Defensive patterns
Strategy: validation
Validate before calling
let hashes = database.get_execution_transaction_hashes(intent.id).await?;
if hashes.iter().any(|h| h.intent_id != intent.id) {
// repair or purge inconsistent rows before recovery
} Prevention
- Enforce foreign keys between transactions and intents
- Never reuse transaction rows across intents
- Audit any tooling that writes to the execution tables
When it happens
Trigger: connect() -> reconcile_unresolved_execution(): iterating hashes from get_execution_transaction_hashes(intent.id), a row's hash.intent_id != intent.id.
Common situations: Corrupted or manually edited database; buggy writer associating transactions with the wrong intent; concurrent writers reusing rows.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- Verified finalized transaction count advanced without an act
- Verified finalized transaction count is outside the owned re
- Verified finalized header extension does not start at the du
- Finalized header ledger conflicts at height {}
- Replacement scan cursor {} is not durably finalized
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/000fa76b6d14b3b8.
Report an issue: GitHub.