-
Notifications
You must be signed in to change notification settings - Fork 37.4k
Avoid divide-by-zero in header sync logs when NodeClock is behind #29647
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
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
This should only happen on regtest, or if the clock is off by years, so no backport is needed |
No change in behavior, only the modern aliases and types are used.
This can be tested on regtest (for exmaple) by connecting a node with one block to a node with no blocks, whose NodeClock is behind the block time. Example outputs (before):
Afterward, they will, more consistently, be assumed to be
|
Concept ACK, will review it soon |
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.
ACK fa4d98b
crACK.
Ran some basic sanity checks: built, and ran all unit and functional tests (all passed).
Started IBD on signet without stale clock.
"Pre-synchronizing" and "Synchronizing" messages looked ok (no negatives or inf observed).
Started IBD on signet with stale clock (about 19 hours behind tip).
"Pre-synchronizing" and "Synchronizing" messages looked ok (no negatives or inf observed).
Yes, this is expected, because the signet chain has a total age of over 19 hours. You could try again, but set the time to be before the first header in the signet chain, and then submit the first header? Or you could try my modified functional test: #29640 (comment)? |
v26.0:
PR 29647:
|
utACK fa4d98b |
tACK fa4d98b I tested this against #29640 by dropping 813961f and cherry-picking both commits included in the PR. Output after dropping 813961f:
Output after cherry-picking:
|
ACK fa4d98b |
The log may be confusing, when the NodeClock is behind the current header tip.
Fix it, by assuming the NodeClock is never behind the current header tip.