Open
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
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.
Description
This is a follow up to the locking feature from #262 and intends to address the issue pointed out in #262 (comment).
Between checking whether the lock exists and placing the lock, another process could place a lock, which is currently not accounted for. As long as a single process is running the migrations, it is not an issue, but if it is part of multiple processes, we have a race condition.
As for the implementation, the lock document is explicitly inserted with an
_idset. This is becauseupsertoperations are still done in two distinct phases on the database side and could end up with duplicate values, unless there is a unique index to prevent this.If we end up in such a tight race condition between two processes, then because of the unique index already present on the
_idfield, we'll end up with the DuplicateKey MongoDB error, which is the same case as when the upsert ends up not creating a new document: the lock already exists.Tests are updated to account for the updated implementation of the locking mechanism and also included a new section in the README about the locks, as it didn't really mention how to enable them before.
+ Added a missing
awaitto the TTL index creation to ensure that the index is ready by the time we try to add the lock to it.Related Issue
Type of Change
Testing
Checklist
npm run lintpasses)npm testpasses)Screenshots (if applicable)
Additional Notes