Locking for jira automation rule

[Hardik Aggarwal]

I have created a jira automation rule, that updates some confluence page when the status of an issue is transitioned to 'done'. Now problem arises when two people or say some script simultaneously update the status multiple tickets. In that case my automation rule fetches the same content of the page to be updated before sending another post request with only one of the updates of the two(race condition to be precise). 

So I wanted to know if there is a way to resolve this using some kind of locking in jira?

[Bill Sheboy · Accepted solution]

Hi @Hardik Aggarwal -- Welcome to the Atlassian Community!

Rather than trying to implement locking for the page updates, why not centralize the changes: use a scheduled trigger rule, and only make updates based on changes since the last run. 

This could be done using a scheduled trigger (without JQL) and a Lookup Issues or Branch on JQL.  If you want to avoid potential problems (due to Atlassian automation outages), you also add an indicator to issues which have already been processed so they are not re-added to the page.

Kind regards,
Bill

[Aron Gombas _Midori_]

Locking can be interpreted in multiple ways.

A

One behavior can be, if one issue is updating the page, then the second (conflicting) update will skipped, then it can be implemented. A dead-simple approach is that the automation should test if the Confluence page has a label "foobar". If not, add this label, update the page, remove the label. If it already has, terminate the rule. (Basically having that label means that "someone is currently updating the page".)

If you don't like using labels, you can use other type of markers, like prefixing the page title with "foobar" or anything else.

B

A potentially better behavior is that the updates should be done one by one sequentially, like jobs in a queue. I don't you can do this with an automation rule.

[Hardik Aggarwal]

For part A, I don't think this will work. Consider the case when the page label doesn't have foobar label. An update comes and tries to add the marker. But inbetween fetching and updating the marker, another update comes and sees the page without marker as well. I don't think this makes the operation 'atomic' and boils down to the original problem.

For part B, Doing updates sequentially isn't in our own hands. Users will come and make updates. We just can't expect them to know about the state of everyone else, whether they are making updates or not!.