-
Notifications
You must be signed in to change notification settings - Fork 20.8k
core: back-up to kvdb for a pruned block #31638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
core/rawdb/accessors_chain.go
Outdated
// The freezer might be pruned. In the particular case of genesis, the block | ||
// will be still available in kvdb. The full genesis block is needed on startup | ||
// sometimes for repair. | ||
if data == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we only specialize the genesis block?
The alternative would be to relax the condition in var headBlock *types.Block
if headBlockNum == 0 {
header := bc.GetHeaderByHash(head)
headBlock = types.NewBlockWithHeader(header)
} else {
headBlock := bc.GetBlockByHash(head)
}
if headBlock == nil {
// Corrupt or empty database, init from scratch
log.Warn("Head block missing, resetting chain", "hash", head)
return bc.Reset()
}
``` |
I was trying to test this patch and hit this panic:
|
Ok after fixing this I am now getting this repeated in my logs and it doesn't proceed:
|
After adding the exception in SetHead:
|
This is an attempt at fixing #31601. I think what happens is the startup logic will try to get the full block body (it's
bc.loadLastState
) and fail because genesis block has been pruned from the freezer. This will cause it to keep repeating the reset logic, causing a deadlock.This can happen when due to an unsuccessful sync we don't have the state for the head (or any other state) fully, and try to redo the snap sync.