enqueue missing parent block if stored in local DB#6122
Conversation
When checking for `MissingParent`, it may be that the parent block was already discovered as part of a prior run. In that case, it can be loaded from storage and processed without having to rediscover the entire branch from the network. This is similar to #6112 but for blocks that are discovered via gossip / sync mgr instead of via request mgr.
| if parent.error() == VerifierError.MissingParent: | ||
| let | ||
| parent_root = signedBlock.message.parent_root | ||
| parentBlck = dag.getForkedBlock(parent_root) |
There was a problem hiding this comment.
why would we have the block here if checkHeadBlock fails with missing parent?
There was a problem hiding this comment.
ie that would indicate that a race happened between index and block write which should be .. rare?
There was a problem hiding this comment.
It happens when there are non-canonical branches from a previous run of the beacon node. We only assign BlockRef to the canonical chain on startup while rediscovering all other branches via sync / request manager. If non-canonical branches have significant length, that takes a very long time.
checkParentRoot actually already logs this case differently from the regular case:
let parent = dag.getBlockRef(blck.parent_root).valueOr:
# There are two cases where the parent won't be found: we don't have it or
# it has been finalized already, and as a result the branch the new block
# is on is no longer a viable fork candidate - we can't tell which is which
# at this stage, but we can check if we've seen the parent block previously
# and thus prevent requests for it to be downloaded again.
let parentId = dag.getBlockId(blck.parent_root)
if parentId.isSome() and parentId.get.slot < dag.finalizedHead.slot:
debug "Block unviable due to pre-finalized-checkpoint parent",
parentId = parentId.get()
return err(VerifierError.UnviableFork)
debug "Block parent unknown or finalized already", parentId
return err(VerifierError.MissingParent)parentId is set to some in case that the block is already available in the database. So, let's just load it from there to speed up discovery of other branches.
When checking for
MissingParent, it may be that the parent block was already discovered as part of a prior run. In that case, it can be loaded from storage and processed without having to rediscover the entire branch from the network. This is similar to #6112 but for blocks that are discovered via gossip / sync mgr instead of via request mgr.