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

[1.0] P2P: Prevent node from syncing too far ahead #638

Merged
merged 5 commits into from
Aug 27, 2024

Conversation

heifner
Copy link
Member

@heifner heifner commented Aug 26, 2024

The change in #572: #572 (comment) allows a node to sync ahead when it receives a irreversible block notice. Need to verify the main thread is not trailing too far behind before requesting additional blocks.

Resolves #635

@heifner heifner changed the title [1.0 P2P: Prevent node from syncing too far ahead [1.0] P2P: Prevent node from syncing too far ahead Aug 26, 2024
@arhag arhag linked an issue Aug 26, 2024 that may be closed by this pull request
@heifner heifner added the OCI Work exclusive to OCI team label Aug 27, 2024
@ericpassmore
Copy link
Contributor

Note:start
group: STABILITY
category: INTERNALS
summary: Optimize pre-fetch block syncing to prevent node from syncing too far ahead.
Note:end

@@ -2203,6 +2208,18 @@ namespace eosio {
sync_next_expected_num < sync_last_requested_num );
}

bool sync_manager::is_sync_request_ahead_allowed(block_num_type blk_num) const REQUIRES(sync_mtx) {
Copy link
Member

Choose a reason for hiding this comment

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

Not a big deal. It would be clearer in the if conditions if blk_num is renamed to next_requested_block_num.

@heifner heifner merged commit c544d5b into release/1.0 Aug 27, 2024
36 checks passed
@heifner heifner deleted the GH-635-sync-ahead branch August 27, 2024 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OCI Work exclusive to OCI team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Node requesting blocks way ahead of forkdb head
4 participants