Automation slow to update Issue Type field

[Kenyon Barnette]

Automations are slow to update Issue Type values. This leads to subsequent conditions in the same automation or separate automations to fail.

Automation "A" is designed to update the issue type field from Type 1 to Type 2. The automation audit log says that the update is taking a long time but it believes that is done. An automation Log Entry action still shows Type 1 as the issue type.

UPDATE: The above screen shot is missing a refetch in the rule. I considered removing it but never published the change. Unfortunately the screenshot was taken when the refetch was removed. It occurs between the Edit Issue Type and Log actions. 

Automation "B" has a trigger of Issue Type Updated. I see the issue from Automation "A" hitting the trigger telling me that the issue type change has been logged. However, the condition to validate that issue type is set to Type 2 fails.

I previously had all of this in a single automation but it was not consistently working. Created separate automations to make sure the issue type was properly set before moving to next steps and it seems that is failing. Curious if this is a performance issue with cloud or the automations themselves. Pure speculation: It seems like the updates are happening on one server while the conditions are being read from a separate server and the replication delay is causing the conditions to fail. Please halp!

[Mykenna Cepek]

I have several thoughts on what you're experiencing.

• Your first screenshot confuses me a little. The Audit Log shows a "Re-fetch issue data" step, but I don't see that in the Rule Details in the left margin.
• I've also never seen the "Jira was slow to respond..." message before. Are you seeing that "Re-fetch" automatically happening in these "slow" cases? If so, that's interesting; I was going to suggest adding a Re-fetch after your Issue Type change.
• Never trust the Audit Log to help you diagnose a timing / race condition in Jira Automation. I've been very vocal about the multi-threaded implementation of automation, which has significant performance advantages, and significant diagnostic disadvantages. Also be aware that Audit Log in loops/branches are non-deterministic.
• I suggest adding a Re-fetch action before the Audit Log action in your Automation A rule. I'd be curious if the logged data then matches your expectation.
• I'd also suggest adding Re-fetch actions in various places in your Automation B rule. At least put one right after the trigger, and see if that makes it work.
• Automation has no functionality to "delay rule execution". You can vote for such a feature here. A known brittle approach, but it cases like these, one wishes for it, at least for diagnostic purposes!
• Your speculative theory is interesting, and probably close. Rather than different servers, I would speculate that it boils down to a combination of: longer time taken for database writes than reads, and database caching for reading data, and the aggressive optimization/multi-threading of automation in general. These race conditions with complex automation rules are no fun. However, these issues do suggest that you might have better luck with a single rule and liberal use of Re-fetch actions.
• I'd more likely suspect that a Jira instance (and automation execution) operates on a different server than where the Jira instance's database is hosted. That architecture would necessitate caching for performance. Would love to hear from an Atlassian Team member to know if I've guessed right on that. 
• Be aware that Re-fetch actions are high-overhead. I added one to a rule recently (for a temporary workaround suggested by Atlassian Support), and it caused us to exceed our automation utilization for a 12-hour period. Ouch. More on those limitations here.

The community (and I) would be interested in learning what eventually works for you. Hope some of the above helps. Good luck!

[Kenyon Barnette]

Thank you for your ideas! Sorry for the confusing screenshot, I had considered removing the refetch and what you are seeing is it removed from the rule but I never published that change. Here is what it looks like:

So, the re-fetch is part of the automation. The "slow to respond" is coming from the first action of editing the issue type. The screenshot of Step 1 shows that the audit log entry after the re-fetch still shows the original issue type. 

The slow to respond message has showed up several times in different automations. Ultimately it appears that the action has taken place but it looks like the API call took longer than the limit on getting a response. I wish that I had control over that because I would increase the limit time so I know that the action was successful before moving to the next step in the automation. 

We look okay on utilization for automations right now and will ask the team their thoughts on adding more re-fetches to the other automations. What is irksome about this is the issue type update is what is triggering Step 2 but it is failing on the conditions validating the change. 

I had previously tried this as one automation with a refetch between actions/conditions and found that the refetch was still showing original values and the conditions were failing. That is why I separated the automations hoping that the action of the first automation will successfully trigger the second (it did!) and pass the necessary conditions (i didn't).

Really appreciate you iterating the speculation and providing more background. That gives me more insight into how this works under the hood. 

[Mykenna Cepek]

Have you (or your colleagues) contacted Atlassian Support at all about the "Jira was slow to respond..." message? Since you've seen it a bunch of times, it might be worth opening a ticket.

Did you try using Re-fetch in strategic spots in your previous "all in one" rule? If not, it might be worth combining these two rules back into one and trying that. At the very least, it will be less impactful to usage limits.

If you contact Atlassian Support, having both efforts (single-rule and separate-rules) in your instance for them to see and replicate will likely save time (as they will almost certainly suggest trying both approaches).

[Kenyon Barnette]

We're fortunate enough that usage limits aren't currently an issue but I am interested in making this more efficient. We're waiting for support to look at a ticket now.

[Rachid El Mansouri]

Hi @Mykenna Cepek

I see that you are comfortable on this topic. 

Could you, please, have a look on my issue and give me your advice : 

https://community.atlassian.com/t5/Jira-Software-questions/Automation-very-bad-performance-on-first-execution/qaq-p/1974847#M191287

Thank you in advance for your time.

[wwalser]

This automation rule looks like it should run fine as-is (with the refetch). 

"Jira was slow to respond" is often an indication of a very active instance or an instance experiencing some systemic issue. Support is the way to go here. From the conversation it appears you've done that and are awaiting more info form them. 👍