Issue

This PR fixes an eth_getBlockReceipts failure when the persisted receipt cache contains invalid transaction-index metadata for a block.

ReadReceiptsCacheV2 reads block receipts from RCacheV2 by walking the block’s txNum range and decoding each cached receipt. The decoded receipt metadata includes TransactionIndex, which is then used to pick the corresponding transaction from block.Transactions() before deriving RPC fields such as transaction hash, block hash, log indexes, and bloom.

Before this change, an invalid cached TransactionIndex was treated as a hard error. For example, block 24,952,410 has 543 transactions, but the cached receipt path could decode a receipt with TransactionIndex = 3,468,750,000
. That index can never be valid for the block, so ReadReceiptsCacheV2 returned:

ReadReceiptsCacheV2: out of range txnIdx=3468750000, len(transactions)=543

That error then propagated to eth_getBlockReceipts, even though the receipt cache is only an acceleration path and receipts can still be derived from canonical block/state data.

For production users, this matters because corrupted, stale, or otherwise inconsistent receipt-cache metadata should not make block receipt RPCs fail when Erigon can regenerate the correct receipts.

Fix

This change makes block-level RCacheV2 reads validate the cached receipt set before using it.

ReadReceiptsCacheV2 now checks that cached receipts match the block transaction order. Since cache entries are read in txNum order, each decoded receipt must have a TransactionIndex equal to the next expected receipt position and must be within the block transaction list.

If a cached receipt has an impossible or non-sequential transaction index, the cache read is treated as a cache miss. The caller can then fall back to deriving receipts instead of returning an internal cache error to the RPC client.

The reader also checks that the cache produced a complete receipt set for the block. Partial cache contents are not enough for block receipt RPCs, which require the full ordered receipt list.

The fix is intentionally small and keeps the cache semantics clear: valid cache data is used as before, while invalid or incomplete cache data is ignored and regenerated from canonical data.

Tests

This PR adds focused coverage for the ReadReceiptsCacheV2 block receipt cache path.

TestReadReceiptsCacheV2BadTxIndex writes a cached receipt with the reported invalid transaction index, 3,468,750,000, for a block with two transactions. It verifies that the cache reader returns a cache miss instead of surfacing an out-of-range error.

TestReadReceiptsCacheV2UnorderedTxIndex writes a cached receipt whose transaction index is in range but does not match the txNum order. This covers stale or inconsistent cache metadata that would otherwise attach a receipt to the wrong transaction.

The existing TestBlockReceiptStorage coverage continues to verify that a valid ordered receipt cache is still read successfully.

Closes: #21194