Adaptavist ScriptRunner for Jira Server Concurrent Operations

Question

Hi, with Adaptavist ScriptRunner v6 for Jira Server v9.2.0, we have encountered the issue where concurrent interactions with Scriptrunner listeners give incorrect outcome.

Steps to reproduce:

1. create 2 listeners, say listener1 and listener2

2. have two users one deleting listener1 and another user deleting listener2 at the exact SAME time

3. note that only 1 listener is successfully deleted, the other one remained undeleted but the response in network tab from the DELETE request gives 204 response code which indicates the operation has been fulfilled on Jira

The issue can also be reproduced when multiple users updating multiple listeners concurrently.

I'm interested to know if this is a known issue in Scriptrunner and whether there is recommended solution to resolve the issue given we have our api product trying to send concurrent requests updating/deleting listeners in Scriptrunner.

PD Sheehan · Accepted Answer

I think you should submit this to productsupport.adaptavist.com.

But I'm not surprised this would be the case since all listeners are stored in the application properties system under a single entry (json formatted):

Select
  e.ID, e.ENTITY_NAME, e.ENTITY_ID, e.PROPERTY_KEY, t.propertyvalue
From
  propertyentry e Inner Join
  propertytext t On e.ID = t.ID
Where
  e.PROPERTY_KEY = 'com.onresolve.jira.groovy.groovyrunner:groovyrunner'

The REST api endpoint probably starts with loading the full list, applying the delete operation, to the list in memory, and then storing the resulting list.

If you call it simultaneously, both threads retrieve the same list, each of them deletes a different one then each of them saves the new list. This is where the concurrency error will happen, the first one to save will put the second one on pause until the record is available, so that the first one will save the new list and return 204 code. Then, when the record is released, the second one saves (with the previously deleted record still in its list) and returns a 204 code.

So both calls were successful, but one overwrote the other.

I think the only way for them to work around this would be to redesign their listener storage and use the AO object instead of the application properties so that each listener has its own row.