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

style: replace next_sync_target Receiver loop with call to wait_for #3618

Merged
merged 1 commit into from
Jul 10, 2023

Conversation

ChosunOne
Copy link
Contributor

@ChosunOne ChosunOne commented Jul 6, 2023

This PR replaces the loop polling in the Header Stage for acquiring the next tip target with a call to wait_for in tokio::sync::watch::Receiver. As far as I can tell, the internal implementation of wait_for is almost identical to the loop used in the Reth code, so I think we should prefer to use the library's implementation over a custom one.

I've also modified the return signature of next_sync_target to return an option so that we can return an error in the event of a channel closure (which previously was hidden). All geth & ef tests pass.

@onbjerg onbjerg added C-debt A clean up/refactor of existing code A-downloaders Related to headers/bodies downloaders labels Jul 6, 2023
@codecov
Copy link

codecov bot commented Jul 6, 2023

Codecov Report

Merging #3618 (2d1bc7d) into main (428a6dc) will increase coverage by 0.01%.
The diff coverage is 66.66%.

Impacted file tree graph

Impacted Files Coverage Δ
crates/stages/src/stages/headers.rs 91.74% <66.66%> (ø)

... and 7 files with indirect coverage changes

Flag Coverage Δ
integration-tests 16.10% <0.00%> (+0.01%) ⬆️
unit-tests 63.95% <66.66%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
reth binary 26.41% <ø> (ø)
blockchain tree 81.25% <ø> (ø)
pipeline 86.91% <66.66%> (ø)
storage (db) 73.48% <ø> (ø)
trie 94.66% <ø> (ø)
txpool 49.11% <ø> (ø)
networking 77.97% <ø> (+0.09%) ⬆️
rpc 58.04% <ø> (-0.01%) ⬇️
consensus 62.10% <ø> (ø)
revm 34.90% <ø> (ø)
payload builder 6.83% <ø> (ø)
primitives 88.28% <ø> (ø)

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

As far as I can tell, the internal implementation of wait_for is almost identical to the loop used in the Reth code

what's the difference?

_ => return Err(StageError::StageCheckpoint(checkpoint)),
};

Ok(SyncGap { local_head, target })
}

async fn next_sync_target(&mut self, head: BlockNumber) -> SyncTarget {
async fn next_sync_target(&mut self, head: BlockNumber) -> Option<SyncTarget> {
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 this now return an Option why is this okay?

Copy link
Contributor Author

@ChosunOne ChosunOne Jul 10, 2023

Choose a reason for hiding this comment

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

I originally wanted to return a Result but the signature doesn't provide enough information for creating a StageError::StageCheckpoint, so the Option is looked at to return a StageError in the event we return None. This is possible because a channel closure was previously unhandled, now it will return None and then return a StageError.

To be clear, the error only appears if the channel has been closed AND the last value has been seen previously. If the channel closes and the last value has not yet been seen wait_for will not return an error.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This is possible because a channel closure was previously unhandled, now it will return None and then return a StageError.

okay I see, because we never handled the error case here (sender is dropped)

@ChosunOne
Copy link
Contributor Author

@mattsse The only difference is that in the event of a channel closure with a previously seen value will return a RecvError rather than ignoring the error.

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

the wait_for and (loop { changed}) are indeed similar

this now returns an option that represents the error case (sender is dropped)

thanks for this

@mattsse mattsse added this pull request to the merge queue Jul 10, 2023
Merged via the queue into paradigmxyz:main with commit 4b261ce Jul 10, 2023
@ChosunOne ChosunOne deleted the use-wait-for branch July 10, 2023 17:24
merklefruit pushed a commit to merklefruit/op-reth-old that referenced this pull request Jul 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-downloaders Related to headers/bodies downloaders C-debt A clean up/refactor of existing code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants