-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Empty fields on eth_getTransactionReceipt
with light clients
#10697
Comments
I feel like this is a consequence of the difference in behavior between geth and parity regarding pending transactionReceipts - we have the same differences in non-light requests - geth returns a null receipt, parity returns what its aware of in the transaction with the undefined values (as the transaction hasn't been mined yet) being null. |
@joshua-mir The transaction isn't pending, it's had 75 confirmations as I write this. I can also replicate this with transactions that were confirmed over 14 hours ago. |
I'd say the issue is that nodes are responding with outdated responses in that case - which would certainly be a valid issue. |
eth_getTransactionReceipt
with light clientseth_getTransactionReceipt
with light clients
The light clients seeing this issue have reserved peers that are my own full nodes that are constantly healthchecked to make sure they're at the latest height. I doubt it's outdated responses, since the reserved peers are the prioritised peers. |
I've tested this with a transaction that confirmed 3 days ago and see the same issue, tx hash
I can go to Ropsten Etherscan and grab any TX ID and the same is shown for them all. |
@jleeh sorry, I misread your original response |
No worries @joshua-mir. I appreciate the very quick responses! |
eth_getTransactionReceipt
with light clientseth_getTransactionReceipt
with light clients
I think the issue is that the I think we should query for RichReceipt but not even this type seems to have all fields though for example Maybe related to #11109 |
Upon calling
eth_getTransactionReceipt
on a confirmed transaction, many of the fields aren't set in the response such as:logs.logIndex
,logs.transactionIndex
,logs.blockHash
.Parity light: request & response
Geth light: request & response
Severity
This issue will cause problems for any application that hangs off light clients when sending transactions and then fetching the receipt. I'd say this is a pretty severe bug in the light implementation.
The text was updated successfully, but these errors were encountered: