Automation running many times per change

Question

I currently have a set of 4 automation rules that listen for field changes across a healthy amount of fields, once a field changed event is fired, the automation rule runs, checks the issue type, then compares the issue create date against a constant date, then triggers a transition on the issue where the event was fired.

The current issue here is that each rule listens to the same 65 fields for changes, what this results in is if for example I go in to an issue, hit the edit button and change a bunch of those fields at the same time that the rule is listening for, the rule triggers many times for the same change operation resulting in this error (or at least that what I think causes this error):

As well as this error sometimes:

One more thing to point out is that either of the errors above are always accompanied by a successful automation rule run.

And this is the automation rule itself:

Is there a way to say if the rule is currently running, don't trigger it again?

Bill Sheboy · Answer

Thank you for explaining the purpose of the rules.  With rules like this, I suspect they will encounter one or more, of the automation service limits: https://confluence.atlassian.com/automation/automation-service-limits-993924705.html  Synchronizing rules like this generally work okay with automation with just a few fields; more fields lead to problems.

I suspect there is no easy, automation-based answer to solve this need.  One that would help is to use a scheduled trigger rule, once-daily, to synch the fields, rather than updated with field changes.  But that may not meet your needs due to the delays in updates.

Instead consider: why are so many fields synchronized between the issues and subtasks?  What value does that provide, rather than going to the other issue (parent or child) for the "source" information?  Considering the process issue may help identify ways to mitigate or resolve this need.

Pierre Ibrahim · Answer

Hi @Bill Sheboy

Thank you so much for taking the time to respond, greatly appreciate it!

The rules' purpose is to copy fields across an issue's subtasks, the fields the rule is listening for are fields the team wanted copied across subtasks (and from subtasks to siblings/parent tasks, thus the 4 automation rules mentioned)

When I had the automation actually do the copying, it was taking too long to run and eventually throttling, and that's why I made the automation rule simply listen for the changes on fields (on edit only, not transition or create), and then trigger the transition.

Unfortunately the transition is an "any to all" type of transition where it simply moves the issue back to the same status, with a post function doing the heavy lifting of copying the fields across subtasks/siblings/parent. With that said, I'm afraid I can't check the status of the issue before the transition action runs, as it will be the same status as before the rule was invoked altogether.

Could I potentially check if the transition was triggered in the last minute instead?

Also adding a refetch is an interesting idea and I might try that, what makes me hesitant in doing so however is I don't want the rule to take longer per run, as another issue I have is due to the sheer amount of changes in my environment in any given day for that specific issue type, my rules are getting throttled. Not consistently though, but enough that I'm trying to streamline the automation rule as much as possible without going to the team that needed the automation in the first place and asking them to pick fields they don't want the automation to listen for anymore. (Which is gonna be plan B if nothing else works)

Please let me know if there's any more detail I can provide, and again, greatly appreciate you taking the time to respond!

Thank you,

Pierre Ibrahim

Bill Sheboy · Answer

Hi @Pierre Ibrahim

First thing, I am using Jira Cloud and not the Data Center version.  And thus my suggestions are based on what I know about rules, in general.  With that out of the way...

I believe your rule structure and errors indicate what is happening: because the rule can be triggered repeated in a short window of time, it is creating timing and collision problems with other executions of the rule.  If you review the date / time stamps in the log you will find this to be the case.

What problem are you trying to solve by checking that many fields with a single rule?  Knowing that may help the community to offer additional suggestions.

Until we know that...

A couple of things to help would be to add two things to your rule:

* Add a Re-fetch Issue action immediately after the trigger* This will force the rule to slow down by about a second, reloading the issue data before processing continues...and likely give the conditions a chance for improved accuracy.

* Add a condition before the Transition Issue action to confirm the issue is not already in the desired next status* This will prevent attempts to transition the issue again if is is already in the status

Kind regards,
Bill