Skip to content
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(exex): finalize ExEx WAL on new finalized block header #11174

Merged
merged 12 commits into from
Sep 25, 2024

Conversation

shekhirin
Copy link
Collaborator

@shekhirin shekhirin commented Sep 24, 2024

Finalizes the ExEx WAL when a new finalized header is received.

In addition to that, a small bug in the Wal::commit was fixed cb58a9e


Tested on Holesky:

  1. The directory for WAL under datadir/exex/wal was created and is currently empty.
  2. On an FCU with a new finalized block, the Wal::commit is called, but since there's no notifications being committed to the WAL yet, it just early returns.
image

@shekhirin shekhirin force-pushed the alexey/exex-manager-finalize-wal branch from aa35526 to 56a643b Compare September 24, 2024 18:22
@shekhirin shekhirin marked this pull request as ready for review September 24, 2024 19:46
fn empty_finalized_header_stream() -> ForkChoiceStream<SealedHeader> {
let (tx, rx) = watch::channel(None);
// Do not drop the sender, otherwise the receiver will always return an error
std::mem::forget(tx);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this leaks, but should be fine for testing

@@ -71,6 +76,7 @@ impl ExExHandle {
node_head: Head,
provider: P,
executor: E,
wal: Wal,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does every exex get a new wal?
doesn't this duplicate a ton of the same data?
this doesn't make much sense to me

Copy link
Collaborator Author

@shekhirin shekhirin Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed, the notifications should be the same for all ExExes no matter how fast they are processing them. Moved it to the ExExManager

}
// If there is a finalized header, finalize the WAL with it
if let Some(header) = last_finalized_header {
self.wal.finalize((header.number, header.hash()).into())?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be fine because we're operating on the assumption that exex will never trail the finalized block, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wdym trail? If you're worried about an ExEx being behind the finalized block, then it's fine because we have this data in the database anyway to backfill the ExEx in case it's behind.

Comment on lines +536 to +537
/// Write-Ahead Log for the [`ExExNotification`]s.
wal: Wal,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should def document why this is even needed.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shekhirin shekhirin added this pull request to the merge queue Sep 25, 2024
Merged via the queue into main with commit 2224e6c Sep 25, 2024
36 checks passed
@shekhirin shekhirin deleted the alexey/exex-manager-finalize-wal branch September 25, 2024 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants