Just an update on the findings. So, the issue is from this line of code: github.com/XinFinOrg/XDPoSChain/bl...
Basically, at the time of this line being executed, the block is missing values for its validator.
The value of block.hash() when validator is missing returned 0x194a513ea40c94fccaca470cccb24c2ff3bd6398dec9a04e3eb3a4bfef8a330e, and this hash has been written into the DB. At later stage, the block is fully finalised: github.com/XinFinOrg/XDPoSChain/bl... Which included the value of validator into its header, and the block.hash() is 0xe8ec0bfc021f839fd0a69ae89689e309632af2cc434e8a096732068f0736864b(this matches the one on canonical chain).
In short, this 0x194a...30e hash does not belong to any block, it's a bug in the code where "in-progress" block somehow had its hash wrote into DB.
I would recommend to ignore this hash value from getLogs API calls. This issue likely to exist in all getLogs calls.
We may try fix this issue in the near future, but it's probably gonna take a while.
I can also confirm the rest of the data in this getLogs shall be accurate(except the blockHash)
For further actions, you may consider blocking this person and/or reporting abuse
Just an update on the findings. So, the issue is from this line of code: github.com/XinFinOrg/XDPoSChain/bl...
Basically, at the time of this line being executed, the block is missing values for its
validator.The value of
block.hash()whenvalidatoris missing returned0x194a513ea40c94fccaca470cccb24c2ff3bd6398dec9a04e3eb3a4bfef8a330e, and this hash has been written into the DB. At later stage, the block is fully finalised: github.com/XinFinOrg/XDPoSChain/bl... Which included the value ofvalidatorinto its header, and theblock.hash()is0xe8ec0bfc021f839fd0a69ae89689e309632af2cc434e8a096732068f0736864b(this matches the one on canonical chain).In short, this 0x194a...30e hash does not belong to any block, it's a bug in the code where "in-progress" block somehow had its hash wrote into DB.
I would recommend to ignore this
hashvalue from getLogs API calls. This issue likely to exist in all getLogs calls.We may try fix this issue in the near future, but it's probably gonna take a while.
I can also confirm the rest of the data in this
getLogsshall be accurate(except the blockHash)