chore: Use transaction for saveUser function#35203
Conversation
|
Looks like this PR is ready to merge! 🎉 |
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #35203 +/- ##
========================================
Coverage 59.64% 59.64%
========================================
Files 2827 2826 -1
Lines 68475 68475
Branches 15177 15182 +5
========================================
Hits 40839 40839
Misses 24989 24989
Partials 2647 2647
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
199176a to
c9de44b
Compare
ricardogarim
left a comment
There was a problem hiding this comment.
Since this is the first time we are implementing session passing, we don’t currently have a guideline or code style for handling it. I’m not sure if we have enough time to use this PR as the foundation for that, but it would be great to start defining some best practices.
For example, we typically aim to remove the options property from service-to-database calls and ensure that model calls are as specific as possible to their use case. Here, we’re introducing more flexibility with options (which I’m okay with), but this could lead to inconsistent calls being made to the same model functions.
apps/meteor/app/lib/server/functions/saveUser/setPasswordUpdater.ts
Outdated
Show resolved
Hide resolved
apps/meteor/app/lib/server/functions/saveUser/setPasswordUpdater.ts
Outdated
Show resolved
Hide resolved
apps/meteor/app/lib/server/functions/saveUser/setPasswordUpdater.ts
Dismissed
Show dismissed
Hide dismissed
apps/meteor/app/lib/server/functions/saveCustomFieldsWithoutValidation.ts
Show resolved
Hide resolved
apps/meteor/app/lib/server/functions/saveCustomFieldsWithoutValidation.ts
Show resolved
Hide resolved
|
Proposed changes (including videos or screenshots)
Currently the
saveUserfunction has a lot of side-effects and interacts with many collections multiple times. This can cause sync issues between records because references can change in one place, and fail to change in another, shortcutting the method execution without a proper rollback. For example, if you change a user's username, and the method that updates the avatar fails, the username will have been changed but an error will be thrown in theusers.updateapi, causing confusion since part of the record change but the rest of the changes might not have happened.This issue was specially prominent during the development of the user auditing mechanism, because it can cause discrepancies between what is being logged and what actually hapenned. It would require to watch the operation step by step or compare records before and after the operation, which also causes discrepancies, as the record can have changed in the mean time that this operation occurs.
This PR aims to make the
saveUserhelper function more solid with the use of transactions. The use of a transaction allows side effects to be skipped in case it fails, and automatically rolls back all operations that are executed within the transaction. It also will throw errors if by any chance there is a concurrent attempt to change the same record, avoiding unintended conflicts due to race conditions.Issue(s)
CORE-1022
Steps to test or reproduce
Further comments