erigon icon indicating copy to clipboard operation
erigon copied to clipboard

some `eth_getTransactionReceipt` calls return `null` for some early blocks

Open XertroV opened this issue 4 years ago • 5 comments

Note: I encountered the issue via using ethereum-etl and scanning through every tx in every block, but the response is replicable via the python web3 package, too (so I think it's probably an issue with erigon). For me, it's reliable for certain blocks (like 209101, 209102, and 209104, but not 209103). It seems to only happen for early blocks -- the last block that triggers this issue is 765998.

For my purposes, this isn't a big deal, but something isn't right. I'm happy to answer Qs on my setup.

I am using --prune=hc.

It seems as though, if a block is effected, then all txs in that block are effected.

System information

Erigon version: 2021.11.3-alpha

(Also happened with a build from around Nov 28 or earlier)

OS & Version: Linux

Commit hash :

INFO[01-12|xx:xx:xx.xxx] Build info git_branch=devel git_tag=v2021.12.03 git_commit=0a31443353b4937b8ead284f2c1e9b1768085820

Expected behaviour

The transaction receipt is returned.

Actual behaviour

null is returned instead (the jsonrpc result is null)

Steps to reproduce the behaviour

Using the python web3 package (the assert fails):

assert w3.eth.getTransactionReceipt("0x035ed34d076f9b9313ccd5016c0ae0508fc9753780f2517e8ebd28ca5b981b4d") is not None

raw jsonrpc request:

{'jsonrpc': '2.0', 'method': 'eth_getTransactionReceipt', 'params': ['0x53e1ee328cd7ba21941a4ca4c9c75b4b46ca7d538c4c0986b048301d2f7e6e4b'], 'id': 0}

(note: there are many txids for which this issue occurs -- I have a record of the block numbers and transaction numbers for all instances, tho. example log for blocks between 200k and 300k: https://gist.github.com/XertroV/9d9cd26e607d4c7560be8efb8cc646f9)

Backtrace

N/A

XertroV avatar Jan 12 '22 08:01 XertroV

Thank, yep, need to fix

AskAlexSharov avatar Jan 12 '22 10:01 AskAlexSharov

Related: https://github.com/ledgerwatch/erigon/issues/6956. Simple examples.

Any status on this?

tjayrush avatar Feb 25 '23 16:02 tjayrush

This issue is stale because it has been open for 40 days with no activity. Remove stale label or comment, or this will be closed in 7 days.

github-actions[bot] avatar Jul 02 '23 02:07 github-actions[bot]

This issue was closed because it has been stalled for 7 days with no activity.

github-actions[bot] avatar Jul 16 '23 03:07 github-actions[bot]

Is there an update on prioritization for fixing this?

I have been able to reproduce this on a number of blocks (not limited by a block height ceiling). I can provide more details if needed. Running version 2.58.1.

The typical symptoms are:

  • eth_getBlockByNumber returns the list of transactions in the block, as expected
  • eth_getTransactionByHash returns null for any of the transactions in the above^ method call
  • eth_getTransactionReceipt (as of v2.58.1) returns block has less receipts than expected: 0 <= 0, block: 0 for any of the transactions in the above^ method call

The blocks that are problematic seem to be arbitrary, as my Erigon instance can get all of the tx receipts for the tx hashes in the OP (of the ones I bothered testing at least).

From reading related issues, there might not be a fix for this besides a clean re-sync? But that won't be much help if there's no guarantee this won't just re-occur in a few weeks, so a concrete fix for this issue would be much appreciated.

Edit: FWIW the node does have the logs that were emitted in the problematic blocks (through eth_getLogs).

boxhock avatar Feb 27 '24 13:02 boxhock