-
Notifications
You must be signed in to change notification settings - Fork 454
fix: move email & sms send out of the POST /user
transaction
#2022
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
hf
wants to merge
2
commits into
master
Choose a base branch
from
hf/move-email-sms-send-out-of-update-user-transaction
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+91
−60
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we thought through the consequences of not rolling back the previous values in the transaction when sendEmailChange fails at every failure point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general I think it should be fine. Yea the email send will fail, but the request will also fail and user can ask for re-send when email sending / SMS sending is back online.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we need to do the rate limit prior the transaction as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with the concerns that we lose the atomicity: if the user updates multiple attributes in one API call(e.g
raw_user_meta_data
andemail
) andsendEmail
fails, the user will have the partial updates(raw_user_meta_data
will be updated even if the call fails). However I don't have the number how many users make multiple changes in one request, so could be OK to ignore.As far as I check the
api.UserUpdate
, all the updates are idempotent (except logging audit entries) so retrying a request in case of sending email/sms fails should be fine.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see. Changed up the code a bit more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That wasn't exactly what I was describing, but it's nice we added the transaction handling to the
sendEmailChange
function 👍I was highlighting the (possible) confusion for the users, when they send the payload below to
api.UpdateUser
and thesendEmail
function fails:In that case, users would get a non-200 response from API but the database would be updated with the new
raw_user_meta_data
values.What about returning success even if sending email/sms is failing? IMHO decoupling notification logic from the request handling would be way to go and in the long run, we can also process the notifications completely async.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it may be worth evaluating some other options, such as:
hookafter
in a more general way, such astaskafter
. This would be clean, simple and keep the operation within the request.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you here, me and Stojan discussed this a little over the weekend and I just have a lot of concerns with changing the behavior of so many flows with the number of writes we do in this tx. I feel there is a subtle security or high impact bug in here somewhere.