You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The deriveLogFields function hydrates a log with information such as block number, transaction hash, block hash ...etc
But in the code below, before deriving the fields isBlockReceipt is called which checks whether the log's transaction hash matches the log's block hash ( block receipts are receipts that are not generated through a transaction, but instead track logs emitted by system calls, as such there is no corresponding transaction so the block hash is used in place of the transaction hash) of course because the fields are not yet defined they will both be zero values and so always match.
I think there is a further problem which is that in the case that len(txs) == len(receipts) the first part of the or condition will not be triggered, so the the next part of the or condition will be triggered, and that will return an error if the last receipt is not a block receipt, even though when len(txs) == len(receipts) no block receipt is expected. This problem probably hasn't been encountered since isBlockReceipt is always returning true in this context.
The
deriveLogFields
function hydrates a log with information such as block number, transaction hash, block hash ...etcBut in the code below, before deriving the fields
isBlockReceipt
is called which checks whether the log's transaction hash matches the log's block hash ( block receipts are receipts that are not generated through a transaction, but instead track logs emitted by system calls, as such there is no corresponding transaction so the block hash is used in place of the transaction hash) of course because the fields are not yet defined they will both be zero values and so always match.I think there is a further problem which is that in the case that
len(txs) == len(receipts)
the first part of the or condition will not be triggered, so the the next part of the or condition will be triggered, and that will return an error if the last receipt is not a block receipt, even though whenlen(txs) == len(receipts)
no block receipt is expected. This problem probably hasn't been encountered sinceisBlockReceipt
is always returning true in this context.celo-blockchain/core/rawdb/accessors_chain.go
Lines 700 to 705 in 91a4db9
The text was updated successfully, but these errors were encountered: