nautechsystems/nautilus_trader · error · anyhow::Error

Profiler log has no block hash

Error message

Profiler log has no block hash

What it means

The profiler watermark log extracted from a receipt must carry a block_hash field to verify it belongs to the expected block. This error is thrown when the RPC-returned log has a null/missing block_hash, so the position check cannot proceed.

Source

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

    );
    let matching_logs = receipt
        .logs
        .iter()
        .filter(|log| rpc_log::extract_log_index(log).ok() == Some(position.log_index))
        .collect::<Vec<_>>();
    anyhow::ensure!(
        matching_logs.len() == 1,
        "Profiler receipt contains {} logs at global index {}; expected exactly one",
        matching_logs.len(),
        position.log_index
    );
    let log = matching_logs[0];
    let log_transaction_hash = B256::from_str(&rpc_log::extract_transaction_hash(log)?)
        .with_context(|| "Invalid profiler log transaction hash")?;
    let log_block_hash = log
        .block_hash
        .as_deref()
        .ok_or_else(|| anyhow::anyhow!("Profiler log has no block hash"))?;
    anyhow::ensure!(
        !log.removed
            && log_transaction_hash == transaction_hash
            && rpc_log::extract_block_number(log)? == position.number
            && rpc_log::extract_transaction_index(log)? == position.transaction_index
            && B256::from_str(log_block_hash)? == expected_block_hash,
        "Profiler log position does not match its ingestion watermark"
    );
    anyhow::ensure!(
        rpc_log::extract_address(log)? == pool_address,
        "Profiler watermark log did not come from expected pool {pool_address}"
    );
    let signature = log
        .topics
        .first()
        .ok_or_else(|| anyhow::anyhow!("Profiler watermark log has no event signature"))?;
    let supported =
        profiler_event_signatures(pool).any(|expected| expected.eq_ignore_ascii_case(signature));

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Wait until the log is mined (block_hash present) before running profiler validation.
  2. Use a full RPC provider that returns complete log objects (eth_getLogs/eth_getTransactionReceipt) instead of a stripped proxy.
  3. Check client/provider version for known bugs omitting block_hash and upgrade.
  4. Re-fetch the receipt via eth_getTransactionReceipt, which should always include block_hash for mined transactions.

Example fix

// before: subscribing and validating immediately
let log = next_pending_log(&ws).await;
validate_profiler_log(&log, &position)?;

// after: only validate mined logs
let log = next_pending_log(&ws).await;
if log.block_hash.is_none() {
    log = fetch_receipt_log(&rpc, tx_hash, position.log_index).await?;
}
validate_profiler_log(&log, &position)?;
Defensive patterns

Strategy: validation

Validate before calling

if log.block_hash.is_none() {
    // fetch the mined receipt instead of a pending log
    receipt = rpc.get_transaction_receipt(tx_hash).await?;
}

Type guard

fn has_block_hash(log: &Log) -> bool {
    log.block_hash.as_deref().map(|h| h.len() == 66).unwrap_or(false)
}

Try / catch

match validate_profiler_log(&log, &position) {
    Ok(()) => Ok(()),
    Err(e) if e.to_string().contains("no block hash") => fetch_mined_log_and_retry(e),
    Err(e) => Err(e),
}

Prevention

When it happens

Trigger: Calling profiler validation when the log object returned by eth_getTransactionReceipt (or a log subscription) has block_hash: null or omits the field entirely.

Common situations: Pending logs (not yet mined) delivered by a websocket subscription; lightweight RPC providers that strip fields; log objects reconstructed manually or from partial eth_getFilterChanges payloads.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors


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