Automation slow to update Issue Type field

Kenyon Barnette_qd13qv

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!