gh-1868 properly propagate "clear links" across commit logs. #1871
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The following situation caused an issue. Imagine there are two commit logs in chronological order: Log 1: - AddLink for Node/Level/Link 0/0/1 - AddLink for Node/Level/Link 0/0/2 Log 2: - ClearLinks for Node/Level 0/0 - AddLink for Node/Level/Link 0/0/3 - AddLink for Node/Level/Link 0/0/4 It should be quite obvious that after reading all the logs back in the correct order node 0 will have the connections [3,4] at level zero, as there was a "clear" event in between. However, prior to this fix we would have ended up with [1,2,3,4] because the clear information got lost when condensing each log independently. This fix makes sure that information that relates to changes from prior commit logs is kept when condensing a commit log. The actual bug was when reading (as part of condensing) as we used the clear only to clear the links (which from the perspective of log 2 were already empty). This led us to condensing log 2 to just "add 3, add 4", whereas the correctly condensed log would have been "clear, add 3, add 4". This is the case now. To write the tests needed for this fix, it was required to add some functional options to the commit logger to control the commit log size thresholds. As of now these are not yet exposed to the user, but this would also add value. fixes #1868 Potential follow-up tasks: 1. Expose Commitlog configuration (e.g. thresholds) to user, so they can finetune them to their needs 2. Clean up the redundant and partly unused code, and the confusion between condensor/condensor2 and deserializer/deserializer2
Codecov Report
@@ Coverage Diff @@
## master #1871 +/- ##
==========================================
+ Coverage 66.27% 66.37% +0.09%
==========================================
Files 415 418 +3
Lines 31433 31740 +307
==========================================
+ Hits 20833 21068 +235
- Misses 8792 8846 +54
- Partials 1808 1826 +18
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
Update: This has been addressed and this PR should be ready to be reviewed/merged. |
This should also fix the flaky test seen on this PR's CI
antas-marcin
approved these changes
Mar 24, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The following situation caused an issue. Imagine there are two commit
logs in chronological order:
Log 1:
Log 2:
It should be quite obvious that after reading all the logs back in the
correct order node 0 will have the connections [3,4] at level zero, as
there was a "clear" event in between.
However, prior to this fix we would have ended up with [1,2,3,4] because
the clear information got lost when condensing each log independently.
This fix makes sure that information that relates to changes from prior
commit logs is kept when condensing a commit log. The actual bug was
when reading (as part of condensing) as we used the clear only to clear
the links (which from the perspective of log 2 were already empty). This
led us to condensing log 2 to just "add 3, add 4", whereas the correctly
condensed log would have been "clear, add 3, add 4". This is the case
now.
To write the tests needed for this fix, it was required to add some
functional options to the commit logger to control the commit log size
thresholds. As of now these are not yet exposed to the user, but this
would also add value.
fixes #1868
Potential follow-up tasks:
finetune them to their needs
between condensor/condensor2 and deserializer/deserializer2