Details
-
Bug
-
Resolution: Timed out
-
Medium
-
None
-
4.2.4, 5.2
-
4.02
-
1
-
Severity 2 - Major
-
5
-
Description
JIRA appears to automatically configure and use an issue listener that handles updating the issue data in the lucene index after most issue events (IssueIndexListener). This issue listener seems to play by the same rules as the rest of the JIRA listeners, in that it is executed in a non-deterministic order with whatever other listeners have been added. If the ordering of this system issue listener falls AFTER the execution of a listener that updates the issue in response to an event, the correct data gets overwritten in the index.
Note the following scenario I have observed with one of our listeners:
- User comments on an issue
- Issue comment event is fired
- Our custom listener is called and updates the issue (new assignee) which in turn triggers the proper events (since we are doing the update via the Jira IssueService).
- A new round of events is fired due to this update
- This triggers a reindex through JIRA's IssueIndexListener that appears to run successfully
- JIRA's IssueIndexListener kicks in again, but now with the original IssueEvent – the one that has the assignee value prior to our update
- Index is updated with the OLD assignee value
The failure to ensure the built in IssueIndexListener runs before user specified listeners basically results in corruption of the index causing invalid data on user dashboards and search results. What makes it even more fun is that everything can be working just fine and the addition of a new listener could cause a reordering that breaks a configuration that was working previously.
Attachments
Issue Links
- causes
-
JRASERVER-30489 Webhooks JQL filtering may not always match
- Closed
- is related to
-
JRASERVER-31325 IssueService in Listener update mismatch
- Closed
- copied to
-
JRADEV-18128 Loading...