-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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: use new engine in e2e tests for OP #13558
Conversation
@@ -43,13 +43,19 @@ async fn can_sync() -> eyre::Result<()> { | |||
.update_optimistic_forkchoice(canonical_chain[tip_index - reorg_depth]) | |||
.await?; | |||
second_node | |||
.wait_block((tip - reorg_depth) as u64, canonical_chain[tip_index - reorg_depth], true) | |||
.wait_block((tip - reorg_depth) as u64, canonical_chain[tip_index - reorg_depth], false) |
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.
this marks whether we need to wait for Finish
stage to advance which might not happen if persistence threshold is not reached
.await?; | ||
second_node.engine_api.canonical_stream.next().await.unwrap(); | ||
|
||
// On third node, sync optimistically up to block number 90a | ||
// Trigger backfil sync until block 80 |
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.
This seems to be an edge case for new engine. If we sync to the tip via backfill sync and then a reorg happens, we're not going to be able to process it because we will be missing trie updates in in-memory state.
I guess this is unlikely because we'd mostly use backfill sync to reach finalized block
CodSpeed Performance ReportMerging #13558 will degrade performances by 10.37%Comparing Summary
Benchmarks breakdown
|
Defaults to new engine when running op e2e tests.
This required some changes to a test