What does the Prevent multiple automations option for Automations really mean?

We are having an issue with the following error showing up in our exception log: 

ScriptException: Maximum scripted extension stack depth (10) exceeded. (An unidentified error occurred within a script.)

My assumption was that the Prevent Multiple Automations would prevent this form happening, but it did not. How should I resolve this Maximum scripted extension stack depth issue?
  • "Prevent Multiple Automations" will not allow you to configure separate automation instances of the same automation type, and attempting to do so would not result in a logged exception, but rather a validation alert if you tried to do that.

    This exception you're seeing logged is unrelated to that, and is instead related to the implementation of the automation type, itself. There's currently a max context depth limitation of 10, which means you can only call core_v2_widget.ExecuteFile('somescript.jsm') up to a depth of 10 times. This doesn't mean you can only call it 10 times, but only 10 times within a single stack, i.e. if an autmation X executes its scriptA.jsm, which executes scriptB.jsm which executes scriptC.jsm etc up to 10 levels deep. Usually, this can be avoided. Would it be possible to share some of the implementation?
  • That makes sense. We have an automation that is randomizing a users Avatar. However we had to use the User Update Event and updating the avatar triggers that event so its stuck in a loop. Is there anyway to avoid that? We can't use the User Created event because our oAuth plugin overwrites the Avatar.

  • Interesting. There are a few different approaches you could try. 

    1 - You could try storing some temp data from your automation when it runs somewhere - potentially in an extended attribute on the user, or with the  context_v2_automationState Script API  to flag that the user's avatar has already been randomized, and so when the automation runs again after updating the avatar, it can check that flag to avoid updating any subsequent times.

    2 - Instead of updating the avatar directly within the automation, you could schedule a background script execution  from the automation with an appropriate delay, and then have the automation run from the user create instead, so that by the time the scheduled avatar change happens, the oauth plugin would no longer have a chance to overwrite. Kind of a hack, but could work. 

    3 - You could potentially update the oAuth plugin to use your randomized avatar instead of whatever it's currently doing on create.

  • Yes I'd agree flagging this as "updated" in an extended attribute would be a good way to manage this, as I would assume you only want to do this once per user ?