[Bug] block timestamp is None in logs from TransactionReceipts

[lukeyyang]

Component

rpc

What version of Alloy are you on?

v0.1.1

Operating System

None

Describe the bug

#429 could be some related prior effort.

The TransactionReceipt contains Log which has an optional u64 block_timestamp. In practice, this value has always appeared to be None. Is this expected?

Note that the block timestamp is available within the block header.

Demo:

use alloy::providers::{Provider, ProviderBuilder, ReqwestProvider};
use alloy::rpc::types::eth::{Block, BlockId, TransactionReceipt};
use alloy::rpc::types::BlockTransactionsKind;
use std::sync::Arc;

async fn fetch_parse_receipts(
    client: Arc<ReqwestProvider>,
    block: &Block,
) -> Vec<TransactionReceipt> {
    let futures = block
        .transactions
        .hashes()
        .map(|tx| client.get_transaction_receipt(*tx));
    let receipts_calls = futures::future::join_all(futures)
        .await
        .into_iter()
        .collect::<Vec<_>>();

    receipts_calls
        .iter()
        .filter_map(|r| match r {
            Ok(Some(receipt)) => Some(receipt.clone()),
            _ => None,
        })
        .collect()
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    tracing::info!("Hello, world!");

    let http: Arc<ReqwestProvider> = Arc::new(
        ProviderBuilder::default()
            .on_http(reqwest::Url::parse("https://mainnet.gateway.tenderly.co").unwrap()),
    );
    let block = http
        .get_block(BlockId::latest(), BlockTransactionsKind::Full)
        .await
        .unwrap()
        .unwrap();
    tracing::info!(
        "Got block {:?} with timestamp {:?}",
        block.header.number,
        block.header.timestamp
    ); // expect to see a valid block_timestamp
    let receipts = fetch_parse_receipts(http.clone(), &block).await;
    for receipt in receipts {
        for log in receipt.inner.logs() {
            tracing::info!(
                "log for block number {:?} with timestamp {:?}",
                log.block_number,
                log.block_timestamp
            );
            // expect to see None for block_timestamp
        }
    }
}

[DaniPopes]

It's a proposed field, and not yet supported everywhere, see

• https://ethereum-magicians.org/t/proposal-for-adding-blocktimestamp-to-logs-object-returned-by-eth-getlogs-and-related-requests
• Proposal for adding blockTimestamp to logs object returned by eth_getLogs, eth_getFilterLogs and eth_getFilterChanges ethereum/execution-apis#295