Open wizzard0 opened 3 years ago
Which network are you on?
mainnet
On 1 Jul 2021, at 11:27, ligi @.***> wrote:
Which network are you on?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Our hunch is that it might be mini 1 block "reorgs". E.g. when a new block becomes canonical in place of an equal height old block. It might be a data race in that case: header gets announced, you request receipts, but by that time another header gets swapped in, so some of the transactions might be "undone".
Could you check if those txs that do get sent back, whether the inclusion header hash matches the one you requested? Could you extend your tester so that if you see a null
, you double check if a new header became canonical?
If you have a snippet you could give us to repro exactly, that would help understand it better.
Yeah the header hash matches, reorgs were the first thing I suspected.
But I receive header 0xaaa, then notification for header 0xbbb, request receipts for 0xbbb, get like half of them (randomly), all referring to block 0xbbb, then receive notification for header 0xccc which references 0xbbb as parent, and nothing else.
If those were reorgs, then I assume I should have received more header notifications?
With tester, do you mean the client code, or try to patch to the node itself?
On 1 Jul 2021, at 11:31, Péter Szilágyi @.***> wrote:
Our hunch is that it might be mini 1 block "reorgs". E.g. when a new block becomes canonical in place of an equal height old block. It might be a data race in that case: header gets announced, you request receipts, but by that time another header gets swapped in, so some of the transactions might be "undone".
Could you check if those txs that do get sent back, whether the inclusion header hash matches the one you requested? Could you extend your tester so that if you see a null, you double check if a new header became canonical?
If you have a snippet you could give us to repro exactly, that would help understand it better.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I observe similar behaviour with a light-mode enabled node. Block hashes and transaction list etc. are all fine but if I invoke eth_getTransactionByHash...
I sometimes receive the tx object with input
being null
.
But this is not easy to reproduce. Trying the call again may return the '0x...' data of the transaction - OR - the field stays 'null' unless the node is restarted.
Must have something todo with error handing/caching in the LES layer and maybe bad peers.
edit Btw, I didn't use batch calls in my example.
System information
Geth version: 1.10.1, 1.10.4 OS & Version: Win10, Ubuntu 18, Ubuntu 20
Expected behaviour
For the batch call over websocket, replies for all requests, for all blocks are consistent.
Actual behaviour
Steps to reproduce the behaviour
eth_getTransactionReceipt
ordebug_traceTransaction
for every transaction.rpc/client.go
right before json.Unmarshal (https://github.com/ethereum/go-ethereum/blob/master/rpc/client.go#L391)Backtrace
N/A
When submitting logs: please submit them as text and not screenshots.