fix(storage-manager): incorrectly revive key after deletion #1689
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.
This commit fixes a bug where a key would be incorrectly "revived" in a scenario where a deletion is followed by a Wildcard Put.
Assuming we have two Replicas, R1 and R2, the problematic scenario was:
z_put "a" = 1 @t1
on Replica R1.z_delete "a" @t2
on Replica R2.z_put "**" = 42 @t3
on Replica R2.After aligning, before this fix, Replicas R1 and R2 would have
"a" = 42 @t3
in their storage whereas there should have been no key associated to"a"
because of the delete at@t2
.This commit fixes this bug.