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
Sometimes bob is trying do download the state for some old block. And since it cannot download it, it cannot accomplish warp-sync. Here is what it says:
The other nodes bob is connecting to and requesting the block are displaying:
2023-11-29 13:42:05.281 DEBUG tokio-runtime-worker sync: Failed to handle state request from 12D3KooWRkZhiRhsqmrQ28rt73K7V3aCBpqKrLGSXmZ99PTcTZby: UnknownBlock: State already discarded for 0x878b918c14b3aaca7cbbd9e91a30e4406a6305222f7ba37fad2b4b382f0b1776
2023-11-29 13:42:06.281 DEBUG tokio-runtime-worker sync: Failed to handle state request from 12D3KooWRkZhiRhsqmrQ28rt73K7V3aCBpqKrLGSXmZ99PTcTZby: UnknownBlock: State already discarded for 0x878b918c14b3aaca7cbbd9e91a30e4406a6305222f7ba37fad2b4b382f0b1776
2023-11-29 13:42:07.280 DEBUG tokio-runtime-worker sync: Failed to handle state request from 12D3KooWRkZhiRhsqmrQ28rt73K7V3aCBpqKrLGSXmZ99PTcTZby: UnknownBlock: State already discarded for 0x878b918c14b3aaca7cbbd9e91a30e4406a6305222f7ba37fad2b4b382f0b1776
2023-11-29 13:42:08.279 DEBUG tokio-runtime-worker sync: Failed to handle state request from 12D3KooWRkZhiRhsqmrQ28rt73K7V3aCBpqKrLGSXmZ99PTcTZby: UnknownBlock: State already discarded for 0x878b918c14b3aaca7cbbd9e91a30e4406a6305222f7ba37fad2b4b382f0b1776
Analysis
The problem starts with the warp-proof that bob receives from alice:
alice just builds the warp-sync proof for the highest finalized block in db while filling the block-gap at the same time.
Random observation: Interestingly latest_justification is not set in WarpSyncProof::generate. The grandpa finalize_block was not set during import of target block from warp-sync.
I'd propose that warp-sync requestor should check if received proof is actually for the requested block (which he knows should be finalized). If not, some additional measures should be performed:
waiting and resending request,
asking another peer,
I think that honest nodes should also do not respond to warp-sync request if the gap-syncing is still in progress.
The text was updated successfully, but these errors were encountered:
The warp sync in following configuration is sometimes failing.
Failure
Sometimes bob is trying do download the state for some old block. And since it cannot download it, it cannot accomplish warp-sync. Here is what it says:
The other nodes
bob
is connecting to and requesting the block are displaying:Analysis
The problem starts with the warp-proof that
bob
receives fromalice
:The grandpa
set_id
and size of proof is different from the warp-proof thatalice
got fromcharlie
:Why is that? Some debugs added, and here is the exciting story of
alice
syncing and handling the warp-proof request frombob
at the same time:Debugs added are here for reference.
alice
just builds the warp-sync proof for the highest finalized block in db while filling the block-gap at the same time.Random observation: Interestingly
latest_justification
is not set inWarpSyncProof::generate
. The grandpafinalize_block
was not set during import of target block from warp-sync.Local node identity cheatsheet:
Proposed solution
I'd propose that warp-sync requestor should check if received proof is actually for the requested block (which he knows should be finalized). If not, some additional measures should be performed:
I think that honest nodes should also do not respond to warp-sync request if the gap-syncing is still in progress.
The text was updated successfully, but these errors were encountered: