-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
feat(bin, engine, prune): spawn pruning task from the engine #3566
Conversation
99c41ec
to
4f10a2c
Compare
Codecov Report
... and 22 files with indirect coverage changes
Flags with carried forward coverage won't be shown. Click here to find out more.
|
fd20012
to
67b745e
Compare
67b745e
to
6ca076b
Compare
this is correct now, yes. We've switched from a background always-running task to a spawnable from engine, so we know the tip block number now, and can pass it to the pruning task. Fixed.
yes, the pruning is blocking and the workload is similar to pipeline's as it will do a lot of db writes.
it doesn't seem now, so I made |
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.
just some questions re poll logic
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.
lgtm
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.
lgtm
in the future (wrt snapshots), we might want to extend and add another event like OnHold
, when we need to prune in chunks using checkpoints
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.
lgtm
fn update_tree_on_finished_pruner(&mut self) -> Result<(), Error> { | ||
self.blockchain.restore_canonical_hashes() | ||
} |
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.
I like having this extra function so we can extend this if we want to call finaluze_block eventually
finally merging 🫡 |
Ref #3439
Flow is the following:
BeaconConsensusEngine
tries to spawn the pruner viaEnginePruneController
.EnginePruneController
callsPruner::is_pruning_needed
with the tip block number to check if pruning is needed.EnginePruneController
spawns the pruning task in a separate thread and sets thepruner_state
toRunning
. Then returns the control toBeaconConsensusEngine
.BeaconConsensusEngine
receives new FCUs during the pruning, it skips it as with the running pipeline.EnginePruneController
sets itspruner_state
back toIdle
, allowingBeaconConsensusEngine
to process any incoming FCUs again.Excerpt from the logs showing that we correctly prioritize engine messages over pruning: