isBlockReceipt incorrectly called on non derived logs

[piersy]

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.

https://github.com/celo-org/celo-blockchain/blob/91a4db91d3b6335f9d2d0bd61e681ad14a438566/core/rawdb/accessors_chain.go#L700-L705

[quickchase]

I noticed that this block: 0x62a443422a49d3778a5723012aaf7649f762be7c95470e57bda2124de528d408 - when you call eth_getBlockReceipts returns a log matching the block hash in the final index...

Is this related or expected?

{"method":"eth_getBlockReceipts","params":["0x1813980"],"id":1,"jsonrpc":"2.0"}

[palango]

@quickchase That's a system transaction, see https://github.com/celo-org/celo-blockchain/discussions/2231#discussioncomment-8229849 for an explanation.