nautechsystems/nautilus_trader · error · anyhow::Error

Finalized execution transaction {tx_hash} no longer has a re

Error message

Finalized execution transaction {tx_hash} no longer has a receipt

What it means

The durable store says the intent reached a terminal status ('finalized' or 'reverted'), but the RPC node returned a null receipt when the reconciler re-fetched it via get_transaction_receipt(tx_hash). For a finalized transaction a receipt should always exist, so this indicates the connected node cannot see the transaction at all rather than a normal pending state.

Source

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

                .mark_execution_event_emitted(intent.id, "acknowledgement")
                .await?;
        }

        let executor = self.transaction_executor()?;
        let prepared = PreparedTransaction {
            intent_id: intent.id,
            created_block: intent.created_block,
            nonce,
            tx_hash,
            raw_tx: current.raw_transaction.clone().unwrap_or_default(),
        };
        let outcome = if matches!(intent.status.as_str(), "finalized" | "reverted") {
            let receipt = executor
                .http_rpc_client
                .get_transaction_receipt(&tx_hash)
                .await?
                .ok_or_else(|| {
                    anyhow::anyhow!(
                        "Finalized execution transaction {tx_hash} no longer has a receipt"
                    )
                })?;
            anyhow::ensure!(
                executor.receipt_is_stably_finalized(&receipt).await?,
                "Persisted terminal transaction {tx_hash} is not stable at the finalized boundary"
            );

            if intent.status == "finalized" {
                InclusionOutcome::Finalized(IncludedTransaction {
                    intent_id: intent.id,
                    tx_hash,
                    block_number: receipt.block_number,
                    receipt,
                })
            } else {
                InclusionOutcome::Reverted(tx_hash)
            }

View on GitHub (pinned to 2114cf6f76)

Solutions

  1. Verify the RPC endpoint serves the intent's chain: compare eth_chainId output with the configured chain_id
  2. Fetch the receipt manually (eth_getTransactionReceipt with the tx_hash from the error) to confirm the node really cannot see it
  3. Switch to a correct, non-pruned RPC provider (or an archive node) and reconnect so reconciliation completes
  4. If the row itself is wrong (tx never landed), repair the intent status in Postgres after verifying on-chain

Example fix

# before: wrong RPC endpoint for the persisted intent's chain
config.http_rpc_url = "https://rpc.other-chain.example"

# after: endpoint matches the intent's chain_id so the receipt is visible
config.http_rpc_url = "https://eth-mainnet.g.alchemy.com/v2/<key>"
assert web3.eth.chain_id == intent_chain_id
Defensive patterns

Strategy: validation

Validate before calling

from web3 import Web3

w3 = Web3(Web3.HTTPProvider(rpc_url))
assert w3.is_connected()
assert w3.eth.chain_id == configured_chain_id, 'RPC chain differs from config'
receipt = w3.eth.get_transaction_receipt(last_finalized_tx_hash)
assert receipt is not None, 'node cannot see the finalized transaction'

Try / catch

try:
    client.connect()
except Exception as e:
    if 'no longer has a receipt' in str(e):
        # endpoint mismatch or pruned node: switch RPC, verify chain_id, then retry
        ...
    raise

Prevention

When it happens

Trigger: connect()-time reconciliation of a terminal intent while: the http_rpc_url points to a different chain than the intent's chain_id, the node pruned ancient history, or a load-balanced RPC endpoint served an inconsistent backend that lacks the block.

Common situations: Switching RPC providers (e.g. from a mainnet endpoint to an L2 endpoint) without updating chain config; using pruned/archive-lite nodes; load balancers routing eth_getTransactionReceipt to lagging replicas.

Related errors


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