Apex Trigger Recursion

Last Modifed: March 21, 2020 by anyei

Having an apex trigger perform a dml operation upon the same sobject type which originated the trigger execution is a very lightweight definition of trigger Recursion in apex.

It gets worse when nothing is in place to prevent this from entering in almost infinite recursion loop. If you don't have code to produce such scenario it might be alright, but you should have code in place to prevent the worse case scenario in case this happens.

This is particularly not such a good thing to happen because there's a governor limit on Salesforce which will throw an exception if the recursion depth is just too much.

Since Atarc Processes are technically executed in trigger context, meaning a DML operation has to happen in order for them to run, they can also fall in this problem. If some code is added into a particular Atarc Process which updates the same sobject which executed it to begin with or any execution call stack which somehow turns out that also updates back the same sobject's trigger which executed the Atarc Process, it could fall into this infinite invocation loop.

Using the LoopLimit from the ATARC Global Settings, will limit how many times does an Atarc Process should be executed wihtin a dml transaction in case that trigger recursion happens, thus preventing this recursion go on in an inifite loop problem. The ideal should be 1 but in case that is needed it can be extended to more than that.

Furthermore, the global settings can have a LoopLimit set to 1, but a particular Atarc Process needs to be executed more than that because a very bad business logic implementation, yet it can be done by overriding the LoopLimit value using the Atarc api or configuration using the Atarc Process Settings.