-
Notifications
You must be signed in to change notification settings - Fork 1
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
Post Launch: Remove Basket lock on global unsubscribe #253
Comments
➤ John Whitlock commented: Paul McLanahan says this can be controlled by a setting, so it can be tried to see the effect without deleting code, and reverted if it causes issues. One reason for this lock (according to code comments) is that Salesforce processes requests async or has eventually consistent databases, so, for example, Salesforce will return success for creating a new contact, but it won't be available in the database until a few seconds later. CTMS currently updates the database on request, so the lock isn't as necessary. It is still possible for two parallel Basket processes to update the same record, but 1) the PATCH API lets you update different fields without conflict, and 2) CTMS could lock for update and serialize the requests. |
➤ Stephen Hood commented: FWIW, a weird observation: last night while testing global unsubscribe in production, I swear that I observed the unsubscribe reason get populated immediately and concurrently with the unsubscribe flag. I was sufficiently surprised as to make a note to ask if this issue had already been fixed! Any ideas? Was I abducted by aliens for 60 seconds? |
➤ John Whitlock commented: I expect some subtle changes now that SFDC is not in the update path, but as far as I know the global lock is still in use. I don't think we are instrumented to peek at an individual unsubscribe request, unless you used a tracing email, and then only on the CTMS side, not basket or bedrock. |
Via [~accountid:60482d4f3ab18c0068d0ff69] : "Basket does unsubscribes async, and has a locking mechanism as well to limit SFDC writes. It takes at least 60 seconds for the second change to a contact. This is painful for “unsubscribe all” in preference center, which is done as one request to unsubscribe, and a second to set the reason. We should remove the lock after launch."
┆Issue is synchronized with this Jira Story
The text was updated successfully, but these errors were encountered: