Handle concurrent settings saving operations #2317
Merged
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
nelsonkopliku
force-pushed
the
fix-concurrency-on-save-suma-settings
branch
from
2aba975
to
0757d3b
Compare
nelsonkopliku
added
bug
nelsonkopliku
force-pushed
the
fix-concurrency-on-save-suma-settings
branch
from
21cbcb9
to
b13e055
Compare
nelsonkopliku
force-pushed
the
fix-concurrency-on-save-suma-settings
branch
from
b13e055
to
dbda3d4
Compare
|
I don't like this solution since we shouldn't enforce constrants on the dabase layer that really belong to domain. Due to the current implementation this is a compromise that the team is taking in order not to rewrite anything. LGTM |
dottorblaster
approved these changes
Feb 16, 2024
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
Fix for concurrent calls to save settings operation.
Currently if two, or more, concurrent requests come to save settings, the database says: ok, I have nothing, you can proceed with insertion to both, or all, requests resulting in multiple records being inserted which later breaks logic relying on the fact we do want only one record there.
The new migration adds a uniqueness constraint and sets a default value for the id, so we don't need to really pass it around in the code and takes care of reusing a previously inserted id, if any.
How was this tested?
Current tests cover desired behavior. Concurrency tested manually.
Reopened as we're trying to figure out what way to go #2327