Details
-
Bug
-
Status: Done
-
High
-
Resolution: Done
-
5.4.36, 5.4.47, 5.4.50, 5.5.6
-
None
-
None
-
American Sprint 106, American Sprint 107, SR Squad 109, SR Squad 111, SR Squad 112, SR Squad 113, SR Squad 114, SR Squad 115, SR Squad 116, SR Squad 117, SR Squad 118, SR Squad 119, SR Squad 120, SR Squad 121
-
5
-
0
Description
This issue has been experienced by two customers in recent months but we are unable to reproduce it reliably.
Issue
Customers are experiencing an issue where, after some unpredictable period of time, event listeners seem to somehow duplicate. When this happens, an older version of the event listener will trigger when the event fires, along with the most current one. If the listener is disabled, the current version ceases to run, but the old handler script continues to run.
Investigation
What seems to be happening is that an event handler will work as expected at first, then after some unknown period of time, probably at some point when the script has been edited, it begins triggering twice - one of which is an older version of the handler. This suggests that the handler is not being unregistered.
Running the following script on a customer's instance which had the issue only returned a single result:
import com.onresolve.scriptrunner.confluence.ConfluenceEventListener import com.onresolve.scriptrunner.runner.util.AOPropertyPersister import groovy.json.JsonBuilder import groovy.xml.MarkupBuilder def items = AOPropertyPersister.loadList(ConfluenceEventListener.AO_PROPERTY_KEY) as List<Map> def writer = new StringWriter() def builder = new MarkupBuilder(writer) builder.pre { mkp.yield new JsonBuilder(items).toPrettyString() } writer.toString()
One possibility is that a race condition is occurring when Confluence tries to unregister the event handler. This would explain why it's affecting so few customers.
Attachments
Issue Links
- mentioned in
-
Page Loading...