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

Header sync incorrectly disregards peers at startup #11930

Closed
Tracked by #73
robin-near opened this issue Aug 13, 2024 · 0 comments · Fixed by #12288
Closed
Tracked by #73

Header sync incorrectly disregards peers at startup #11930

robin-near opened this issue Aug 13, 2024 · 0 comments · Fixed by #12288

Comments

@robin-near
Copy link
Contributor

This is a subtle startup corner case. When starting up,

  • We wait for the number of peers to pass a certain threshold before entering sync, but there is a delay between we pass that threshold and when we actually enter sync.
  • Meanwhile, we may have a peer that sends us a new block
  • We have logic that if we receive a block and we're not syncing, and the block is way too high, we consider the block as invalid and remember the block hash as invalid
  • When we then consider whether we're ready to enter sync, we throw away that peer because the peer's highest block is a known "invalid" block, therefore the peer is not eligible and we have not enough peers.
  • This cycle repeats.

Perhaps it makes sense to add a initial state, instead of NoSync, make it InitializingSync or something, during which we don't ban incoming blocks.

github-merge-queue bot pushed a commit that referenced this issue Oct 28, 2024
* GC prints error because the head is at genesis. Return early in that
case. Otherwise while we're doing epoch sync because head remains at
genesis, this keeps spamming the logs.
* See #11930 for a header sync problem; a recently received block is
marked as invalid because its height is too far ahead of where our head
is (genesis). We fix this by not marking blocks as invalid if it's just
because of height. The reason why we mark a block as invalid is because
we think that the block can never be valid (e.g. due to some state
disagreement) so we should not bother trying it again, but if invalid
height is the issue, this is counterproductive.

Closes #11930 
Closes #11936
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 a pull request may close this issue.

1 participant