Update session.ex add ServerSession.next_txn_num when ending the session to prevent silent no-write operation #287
Conversation
This file contains hidden or 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
…ion to prevent silent no-write operation fix retryable_write faulty, fix the issue that prevent replace_one to occures on concecutive update on the same document when sessions is checkin and then reused again (same document or different does matter, it's stays silently blocked until the session expires)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Context:
I was testing the feature
Mongo.replace_onewith the enabled params :upsert: true, retryable_writes: truewhen I found out that none of my document was getting updated despite the change on the documents every time from an extract to next the very first attempt to replace_one.The digging
After some investigation I found that the issue was linked to the
retryable_writesbehaviour that was "using/re-using" the same sessionslsidandtxnNumber.From the documentation reusing the same
lsidwas supposed to be ok but not fortxnNumber, I was surprised to discover that thelsidandtxnNumberwas staying exactly the same after multiple find_one followed by some minor change on the doc followed by an attempt to beMongo.replace_oneagain. (the session_server was reused without increasing thetxnNumber)Thanks
Big heads up to log feature:
log: &IO.inspect/1that helped a start diagnose it even from a novice experience on the driver it selfI did some dummy test on own, and it solved my issue.
I may still have miss edge case so, Peers review will be very appreciated, I'm still very on the learning curve of the driver