ScriptRunner and Post Function Scripts order and execution

Throwing this one out there, hoping that @Jamie Echlin [Adaptavist] or @Henning Tietgens can help with this one. 

So, I've had a few problems with a set of post functions and fast tracks. One of my fast tracks was getting "skipped" because of a re-index that took too long, thus not updating certain fields to meet the conditions of the "Back to Reopened" fast track.

My problem now is that my script Sleep.groovy, using Thread.sleep(10000) to delay the post functions by 10 seconds after the index, is not doing the job.

My questions:

  • Do the Post Functions execute the script then immediately move on to the next Post Functions while the script continues to execute?
  • Or does it allow the entire script to execute, then upon completion, move to the next Post Function?
  • Is there a way to script a delay that will halt the entire flow of the Post Functions to allow for a complete indexing? Or some kind of listener that can wait for it to complete?

postfunctions.PNG

 

11 answers

In answer to the bulleted list in the original question:

Script post-functions get executed synchronously, in the order that they're listed on the postfunctions page. There's no concurrent execution, so sleeping won't help you delay until after other postfunctions have run.

Per Jamie's answer on your other question, the easiest way to get asynchronous execution would be to start a new thread. e.g.

Thread.start{
    log.debug("Running first script postfunction")
    Thread.sleep(5000)
    log.debug("Completing first script postfunction")
}

You could adjust the sleep as appropriate, do checks for certain things to be ready before starting work, and so on.

it seems does not right, I have 2 script runners to create a bunch of subtasks, I expected they are created in order but actually they are mixing up

0 votes

I've flagged it but I'm not going to get to it tonight.

No problem! My gut tells me this is related to load on JIRA as my workflow tested successfully before implementing. We've seen dramatic increases in use and this problem seems to correlate with that. My thought was that perhaps the index hasn't been updated to the programmed status when the fast track transition is called. We updated the workflow to eliminate the programmed status (using transitions with the same original and destination statuses), hide the fast tracks base on conditions and execute the appropriate transition but we still get the error and it seems to mostly occur on the first two fast track transitions (12 and 13 in the image above). Did I mention this is intermittent?

0 votes
Henning Tietgens Community Champion Sep 24, 2014

Could you show the conditions for the fast track postfunctions? And what error did you get?

@Henning Tietgens, these are the style of the conditions: cfValues['hidden readonly workflow field 1'] == 'Open' And errors were: Error Messages: [It seems that you have tried to perform a workflow operation (Back to Open) that is not valid for the current state of this issue (TESDD-3). The likely cause is that somebody has changed the issue recently, please look at the issue history for details.]

0 votes
Henning Tietgens Community Champion Sep 24, 2014

Are the conditions for the fast tracks mutually exclusive? Did one of the fast track transitions change the field which is used in the following fast track conditions? If one of them is executed the next one may not work.

They are mutually exclusive. In fact, each fast track has been tested and works 99% of the time if moved to the last position in the order of the post functions. The ones that consistently had problems were always immediately after that indexing/event firing. Occasionally, the second one after indexing/event would have issues which we now conclude was due to server load and a longer index time. Basically: whichever fast track is right after that index is testing the condition, but it seems like the issue has not re-indexed by that point. Which ever fast track is in that position will always fail. Once the attempted transition is done, and I'm stuck in the wrong status, I can perform the transition manually with no problem.

0 votes
Henning Tietgens Community Champion Sep 24, 2014

Ok, I have to handover to Jamie... Within the fast track postfunction the transition is started as a separate thread which first sleeps for 100 ms, maybe this isn't long enough for your system.

So yeah... I think my options are to 1) extend that sleep to 1000ms/2000ms for at least the first fast track or.... 2) determine if it is possible put a script into the post function following the indexing which listeners for completion of the index and stalls the post function steps until index is completed.

An update: Doubling the fast-tracks did not solve the issue. Neither did Thread.sleep'ing them prior to the condition being tested. My rough estimation of how it goes: 1. Re-indexing 2. Fast-track 1 fails 99% 3. Fast-track 2 fails 90% 4. Fast-track 3 fails 50% 5. Fast-track 4 fails 20% 5. Fast-track 5 fails 1%

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,815 views 11 18
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot