Which triggers in the automation rules exhibit race condition errors?

[Bill Sheboy]

Greetings, community!

My teammates have increased use of automation for JIRA to solve many problems, and early on we noticed the race condition errors with the Create Issue trigger.  When this happens, the issue's fields are not fully loaded/available at the time of rule processing.  Our work-around is to place a Re-fetch action immediately after the trigger.

As we become more reliant on the rules working, we want to pro-actively add re-fetches where needed.

Which other triggers have people used where you observed a race condition error?

Thanks for any information you can provide!

[Susan Hauth _Jira Queen_]

Hi Bill,

We recently ran into a race condition using Automation for Jira (Server).  When the issue is created based on a field value, we transition it to the next status (in our case we use the automation to transition from Incoming Queue to the DBA queue).

Almost always we were finding that the status transitioned but the visible status was incorrect (displayed Incoming Queue) but in fact it was in DBA Queue.  Every now and then it worked.  We thought it might be related to some 3rd party post functions but couldn't really nail it down to anything.  Re-fetch did not help.

After many weeks with Atlassian we gave up after the explanation of "race condition".  Instead I set up an automation rule in the Service Desk automation to transition to DBA Queue and that has worked 100% of the time.

Hope that helps...

[Bill Sheboy]

Thanks, @Susan Hauth _Jira Queen_ for the idea. 

I expect that other than re-fetch, another work-around is to split processing between multiple rules, forcing a slow down until data is present for processing.

We recently saw a different race-track symptom, with random unsaved changes errors during rule execution.  Support told us this is was API performance-related and that they expected this to improve with the on-going performance changes by the development team.  My hope is that the performance changes are accompanied by transaction improvements in the API so triggers do not get fired out of temporal sequence, as they appear to do with Create Issue currently.

Best regards,

Bill

[Earl McCutcheon]

Hi @Bill Sheboy ,

Thanks for the info, and there are a few race condition Bugs we are currently aware of, that you can check out a "THIS LINK" .

But overall any time you can trigger a race condition we do want to file it as a bug if we can reproduce the behavior so we can work on fixing it. 

Do you happen to have a little more detail of how the rule is set up so I can take a closer look and get this one filed as a new bug.

Regards,
Earl

[Bill Sheboy]

Hi @Earl McCutcheon 

Thanks for the info.  The link you provided shows as invalid/blocked for me.  Would you please update it?  Will that information show other triggers which have timing issues?

Regarding your question about details for race conditions, I know of two specific scenarios:

• Create Issue 
  • When an issue is created and the event is captured by the trigger check, there can be timing issues using the information in the created issue in conditions or field edits.
  • This appears to occur because the API makes the create event visible before the issue has saved, and so the issue contents are not consistently available.
  • The work-around I use for this situation is to add a Re-fetch Action immediately after the trigger.  This usually provides enough of a delay that the re-load has the issue's full data from the time of create.
• Use of branches
  • As noted in other posts and suggestions, branches lead to splitting up the target issues for parallel execution.  Each appears to be queued independently, leading to faster, albeit non-deterministic processing.
  • Any rule which has a branch and which attempts to use the results of actions happening within the branch *after the branch* can have timing issues.
  • I have not used this yet, but a work-around (hack) I envision is using semaphore flag fields, set at the start of branch processing and cleared at the end.  An independent rule could then be used to process actions which needed to occur after all/some branch process was completed by checking flag fields.

If there are other scenarios, perhaps the community can post them to help with rule execution improvements.  Thank you!

Best regards,

Bill