Fix problem with manual setting pendingFCU
#3788
Conversation
why
Setting this field before running `finalizedBlockHash()` will
lead to mismatched number/hash information in the `FC`
descriptor if the current finalised block already registered
is child of the one to used for updating.
This happens because the function `finalizedBlockHash()` will
end up calling `tryUpdatePendingFCU()` which has an effect only
if the update is child on the already stored register.
In case that the update is parent when `tryUpdatePendingFCU()` has
no effect, before this PR one ended up with a (new) hash of the
parent header, and an already registered block number of the child.
how to reproduce
+ Use the latest manual finalised sync target while the `CL` is
still catching up syncing.
+ Switch between `CL`s with different sync states or run them
simultaneously.
|
It is normal that we don't know the number of the fcu and that there's a mismatch - I'm not sure why this is being removed - the idea is that when the hash becomes known, the number is updated accordingly. |
|
Problem appears when hash and block number already exist and a parent block hash is added by overwriting the This is all handled correctly by I saw your PR #3257 from 5/5/25 but there was no comment why this statement (now to be removed) was added. The effect of this mismatch was that the But I see that a solution might also be that the |
|
Thinking of it, using a second register |
you can just look up the block by number and take the hash from there - |
2 participants
No description provided.