-
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
fix(engine): use provider to initialize persistence state #9785
Conversation
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.
hmm, should these be initialized with the current on disk head?
but I guess we can make these an option first until we have an initial persistence run?
reth/crates/engine/tree/src/tree/mod.rs
Lines 389 to 390 in 527cc44
let best_block_number = provider.best_block_number().unwrap_or(0); | |
let header = provider.sealed_header(best_block_number).ok().flatten().unwrap_or_default(); |
yeah actually that would be better |
6904cd0
to
e82a424
Compare
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!
failing test |
Previously, on node startup, these would be zero, making `should_persist` always true, also causing the engine to send empty blocks to `save_blocks`. Now these are options, which are only set when a persistence task finished. Otherwise, the start for any persistence distance measurement will be the minimum block stored in the tree.
e82a424
to
885cdc7
Compare
Previously, on node startup, these would be zero, making
should_persist
always true on startup, also causing the engine to send empty blocks tosave_blocks
.Now these are initialized using values from the provider factory, which should correspond to the values that are actually on-disk.