Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Which triggers in the automation rules exhibit race condition errors? Edited

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!

2 answers

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.


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,


0 votes

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...

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,


Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Marketplace Apps & Integrations

Jira issue check and more advanced commit verifications for Bitbucket DC

Pre-receive hooks that verify the Git commit message, the modified files, and implement similar code change controls used to be requirements of large enterprises working in regulated industries only....

31 views 0 2
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you