Automation For Jira Order Of Operations For Actions: Need Sleep Function

[Adam Dulberg]

Hello Community,

@atlassian this is a product request that I will follow up with our account rep. I've run into minor issues with order of operations where actions occur not in the order they're listed, but by some race condition. For example, I have an edit field rule immediately followed by audit log. I'm finding that the field is actually edited (confirmed by viewing the issue), yet the audit log isn't reporting that field. The issue is not what I wrote to the audit log, take my word that this is an order of operations problem.

I have experienced other examples where I need to actually change my rule because the running of operations makes the rule ineffective. My request is for a pause/sleep operation where the API can get caught up before enacting on rules placed further down the list. 

If I am missing something and there is a way to work around order of operations would love for someone to share.

Thanks

[Bill Sheboy · Accepted solution]

Hi @Adam Dulberg 

First thing, I am just a user offering input, and not an Atlassian employee.  With that out of the way...

I did not find any suggestions in the public backlog for this idea, and you may add one if you wish.

Update: I did find these two suggestions in the Code Barrel backlog (now part of Atlassian)

• https://codebarrel.atlassian.net/browse/AUT-253
• https://codebarrel.atlassian.net/browse/AUT-1775

And, based upon your rule design there definitely could be timing issues.  For example, anything inside of a branch which covers more than one issue is executed asynchronously and thus there is no guarantee of when that processing finishes.

Perhaps if you post an image of your rule and audit log, and explain what you expect versus what you observe, that will give the community some context to offer suggestions.  Thanks!

Best regards,
Bill

[Adam Dulberg]

Thanks for the finds @Bill Sheboy

It would seem that both focus on the crux of the issue. Yeah I'm wondering if branching on the rule (to run on 'current issue') would help in this case. Ultimately I don't know how the backend works so it's a bit of a crapshoot. The edit "Amount" field is a simple calculation from a couple of other smart values (not advanced edits).

This is the most basic rule where I've seen it fail due to timing. I've attempted more complicated if/else blocks with handfuls of steps (running only on the current issue), so without a concrete understanding it doesn't make sense to dive into those.

Even if there is a workaround the sleep/pause/delay would still make things a lot simpler. 

 

[Bill Sheboy]

Hi, Adam!

Thanks for the rule image.  Do you mean that when you edit the Amount field within a rule, and then log it to the audit log, the updated value is not logged?  If so, that functions as documented.

The rule loads issue data at the moment of trigger, and when you change fields they are updated *in cloud storage*, however the loaded values have not changed.  For your example, you would need to use a Re-fetch action after the edit to then log the changes.  So not a timing issue for this example.

And...there are known timing issues related to triggers, particularly Issue Created, where all of the data is not yet available when the rule fires.  The work-around for that is to add a Re-fetch action after the trigger, which slows down the rule and re-loads the issue before further processing.

__Bill

[Adam Dulberg]

Yeah Bill that's it refetch worked for this situation. The option was available as an Action. Kudos thank you.

[bmccoy]

Hi,

Looks like you've got this figured out but just to fill in the blanks a bit:

In this scenario, it is not a timing issue but a performance optimisation.  Any changes that you make to the issue during execution are not reflected automatically for subsequent steps.  This would require a round-trip to Jira so could slow your rule down unecessarily - so we don't do it. 

As you've discovered, adding the re-fetch forces Automation to go back to Jira and get the updated values only if you need them to be there.

Cheers,
Brydie

[Adam Dulberg]

I'll mark Bill's answer as the right approach since there isn't a clear cut answer and those two tickets do seem to address the core of the problem.

Would still appreciate a functional albeit temporary solution if someone is familiar with how to work around this issue given the current toolset.

[Adam Dulberg]

Disregard - see updated thread with Bill

[Fabian Lim]

@Adam Dulberg

I would recommend using 2 rules instead and use this post about calling rules from another rule. https://community.atlassian.com/t5/Jira-Software-questions/Automation-how-to-calling-rules-from-another-rule/qaq-p/1347348 

Cheers.

[Adam Dulberg]

Thank you for the recommendation @Fabian Lim

I can envision a handful of situations right off the bat where that would be helpful. For a simple case like audit logging though, this would be a hassle. For larger topics I will keep this in mind.