Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Use rounded derived height sync param #2364
Use rounded derived height sync param #2364
Changes from 1 commit
b91b8bf
41ef0c2
771fe83
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
afaik, as soon as sync params are present, mm2 will start syncing from scratch from the specified date/height, mo matter what it's in the DB
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.
only if height != db_height
see https://github.com/KomodoPlatform/komodo-defi-framework/pull/1922/files#diff-878c719c6e82f1f4290cc74719c8a7de8e3ef2d5927ebbee5925e3dd54655cfcR381-R382 and https://github.com/KomodoPlatform/komodo-defi-framework/pull/1922/files#diff-878c719c6e82f1f4290cc74719c8a7de8e3ef2d5927ebbee5925e3dd54655cfcR487
@borngraced can you please confirm?
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.
yes only if derived starting_height != to the minimum height in db
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.
can't follow the links to the code, it's not jumping to the specified line, so i will just trust you :-)
ok, so we rely now on some height calculation based on a 60s blocktime which can vary a lot on ARRR
does it mean there is still a chance that my app will start syncing from scratch if the calc is off eg because blocktime was 120s in the last 2 weeks? is there a way to avoid this 100%? it takes 2 days to sync from scratch and i want to avoid this at all costs, so i rather prefer to remove sync_params completely from my repo then to risk syncing from scratch
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.
ok, guess if i have the date set at 2 days and the DB is 2 years old, it should never happen... just need to think to reset the date back to 2 days ago after a complete resync from 2 years ago
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.
yes right
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.
https://github.com/KomodoPlatform/komodo-wallet-desktop/pull/2367 has been prepared for the next release (0.6.2) after current API dev branch is merged.
The calculated avg block time between the checkpoint block (19000000) and the current height was a little over 63 seconds. In the GUI side date to height calc, I've assumed a 65 sec avg blocktime (to avoid recent dates potentially returning a block_height > tip) calculated as an offset from the checkpoint block (middle out reduces the cumulative overage compared to edges in).
This calc will generally return a height for a date which errors on the side of being earlier than actual, which is better than later than actual, for example if user knows the date of a tx and syncs from there but the calc sets it ahead a day, the sync excludes the tx. If set earlier, it is sure to be included.
The real problem though that this PR aims to fix is the potential for the date to height calc to return a different value when run again later, due to the rate of block production between the first and second runs. This changed block height may force a rescan even if selected date remains unchanged, and the odds this will happen increases as the time between first and second run increases. By rounding the result to the nearest 1000, it is much less likely for this to occur, and in a large majority of cases, the returned height will be the same so that no resync is triggered and the sync will continue from the prior cache height.
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.
If we get reports that rounding to 1000 still results in cases of forced resync, we can change the rounding factor to a higher value, though a value of 1000 should be enough to overcome most periods of excessively high or low block production unless they are uncharacteristically extended before reverting back to the mean.