fix: expirations on huge values #4297
Draft
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
adiholden
reviewed
Dec 12, 2024
| @@ -453,7 +453,7 @@ OpResult<DbSlice::PrimeItAndExp> DbSlice::FindInternal(const Context& cntx, std: | |||
| } | |||
|
|
|||
| if (res.it->second.HasExpire()) { // check expiry state | |||
| res = ExpireIfNeeded(cntx, res.it, true); | |||
| res = ExpireIfNeeded(cntx, res.it, false); | |||
There was a problem hiding this comment.
when we call FindInternal we always hold the lock to the key, or at least we should, if not its probably a bug
There was a problem hiding this comment.
yes and I think I am wrong here as well. There is something else that is happening.
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.
I managed to reproduce locally the https://github.com/dragonflydb/dragonfly/actions/runs/12290843825
The problem is that there are flows that hold no locks to the keys (it's not inline transactions because I fixed that while ago) so when we preempt when we call
ExpireIfNeededwe first write to the journal, context switch to another fiber and then we finally delete the entry. If the fiber that we switched modifies the same key then we get the data inconsistency because after we resume back from the write to journal we will delete the key.I am not yet sure which flow does not lock the key and I am currently investigating that.
The test no longer fails locally with this small change.
P.s. now all of our
ExpireIfNeededcalls require to the journal write tonot preempt. So we are kinda back onExpireIfNeededalways requiring to not preempt.I would rather not merge this yet until we understand exactly where we don't lock the keys.