ScriptRunner and Post Function Scripts order and execution

[Kyle Moseley _blueridge_cx_]

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

[Jonny Carter]

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.

[Vinh Lam]

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

[Paul]

Hi Vinh,

Have you find the solution for the problem?

I have similar issue - when I create few sub-tasks, they are not displayed in order (probably due to ranking "mixed" assignment.

[Vinh Lam]

Hi,

In one thread, it is usually in order. my problem was in different thread. A workaround I did is adding sleep in the second one so that it can run after 

[Paul]

Thanks Vinh,

That (sleep) actually solve the problem. Not the perfect solution but at least it works.

[Kyle Moseley _blueridge_cx_]

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%

[Kyle Moseley _blueridge_cx_]

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.

[Henning Tietgens]

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.

[Kyle Moseley _blueridge_cx_]

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.

[Henning Tietgens]

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.

[Kyle Moseley _blueridge_cx_]

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

[Henning Tietgens]

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

[Trevor Hunt]

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?

[JamieA]

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

[Trevor Hunt]

Any takers?