-
Notifications
You must be signed in to change notification settings - Fork 469
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
catchup: make unsupported block handling more deterministic #5673
Conversation
The catchup code had a race where, upon seeing an unsupported block in the future, the catchup logic would cancel the current pipeline of block fetches. Depending on the timing, this might either make some progress or not fetch any blocks at all. The new logic is more deterministic: it tries to always fetch all blocks up until the last supported block, and when the ledger reaches the last supported block, the catchup service stops.
Codecov Report
@@ Coverage Diff @@
## master #5673 +/- ##
==========================================
+ Coverage 55.15% 55.16% +0.01%
==========================================
Files 465 465
Lines 65003 65011 +8
==========================================
+ Hits 35850 35862 +12
- Misses 26760 26761 +1
+ Partials 2393 2388 -5
... and 8 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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 is a welcome fix. However, I share @algorandskiy 's concern.
I have a suggestion to trigger the monitor only after an unsupported is detected.
I have a draft for this here.
Fair enough. How about the change I just pushed, to start the |
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.
Good
the GH-CI integration stuck, closing and reopening to retrigger. |
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.
Very nice.
The catchup code had a race where, upon seeing an unsupported block in the future, the catchup logic would cancel the current pipeline of block fetches. Depending on the timing, this might either make some progress or not fetch any blocks at all.
The new logic is more deterministic: it tries to always fetch all blocks up until the last supported block, and when the ledger reaches the last supported block, the catchup service stops.