UNABLE_TO_LOCK_ROW exception while Merging Contacts via Plauti Duplicate Check

[kanavmuscle]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

Merge a Contact using the Plauti Duplicate Check (https://www.plauti.com/products/salesforce/duplicate-check)

Expected behavior
The Contact merge should happen without any errors.

Screenshots
Error message:

Debug Logs:

Note: As you can see, the exception is thrown as soon as the transaction flow enters the DLRS package.

Additional context

• Plauti is a managed package as well

[aheber]

@kanavmuscle what version of DLRS are you running?

[kanavmuscle]

Thank you for getting back. At the moment, we have Version 2.17.

…

________________________________ From: Heber ***@***.***> Sent: 26 June 2024 21:11 To: SFDO-Community/declarative-lookup-rollup-summaries ***@***.***> Cc: Kanav Khurana ***@***.***>; Mention ***@***.***> Subject: Re: [SFDO-Community/declarative-lookup-rollup-summaries] UNABLE_TO_LOCK_ROW exception while Merging Contacts via Plauti Duplicate Check (Issue #1478) @kanavmuscle<https://github.com/kanavmuscle> what version of DLRS are you running? — Reply to this email directly, view it on GitHub<#1478 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BI5XWP7IFTV6XGH3U44TE3TZJMG5JAVCNFSM6AAAAABJR64OHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJSGQ2TCMRVGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[aheber]

Newer DLRS versions (v2.21 is the most recent) include a small amount of help in this domain but not much.

None of the realtime updates include explicit locking behavior, only the necessary locking to update the record. DLRS also doesn't use multiple transactions so if this transaction locked the record it would be fine, something else is likely spawning a record lock in parallel, it is possible that the other transaction is also triggering DLRS to act which could, in a narrow way, cause DLRS to fight itself but DLRS wouldn't be the instigator for that.

I don't think DLRS would be able to make any reasonable changes to improve this, aside from testing with the latest version which avoids writing value to parents if they would be the same (which may or may not help you). You may need to look at either moving to a scheduled calculation mode so we don't try and update the master record right away or moving to a scheduled full calculate so you don't need any trigger or monitoring on the contact at all.

[kanavmuscle]

Thanks for the help! I will try these things.

…

________________________________ From: Heber ***@***.***> Sent: 27 June 2024 21:12 To: SFDO-Community/declarative-lookup-rollup-summaries ***@***.***> Cc: Kanav Khurana ***@***.***>; Mention ***@***.***> Subject: Re: [SFDO-Community/declarative-lookup-rollup-summaries] UNABLE_TO_LOCK_ROW exception while Merging Contacts via Plauti Duplicate Check (Issue #1478) Newer DLRS versions (v2.21 is the most recent) include a small amount of help in this domain but not much. None of the realtime updates include explicit locking behavior, only the necessary locking to update the record. DLRS also doesn't use multiple transactions so if this transaction locked the record it would be fine, something else is likely spawning a record lock in parallel, it is possible that the other transaction is also triggering DLRS to act which could, in a narrow way, cause DLRS to fight itself but DLRS wouldn't be the instigator for that. I don't think DLRS would be able to make any reasonable changes to improve this, aside from testing with the latest version which avoids writing value to parents if they would be the same (which may or may not help you). You may need to look at either moving to a scheduled calculation mode so we don't try and update the master record right away or moving to a scheduled full calculate so you don't need any trigger or monitoring on the contact at all. — Reply to this email directly, view it on GitHub<#1478 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BI5XWP7DERR6F2OAASQIQB3ZJRP2DAVCNFSM6AAAAABJR64OHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJVGQ4TGMBVHA>. You are receiving this because you were mentioned.Message ID: ***@***.***>