-
Bug
-
Resolution: Fixed
-
Highest (View bug fix roadmap)
-
8.20.0, 9.4.1, 9.4.10, 9.4.14, 9.12.1, 9.12.7
-
None
-
8.2
-
38
-
Severity 2 - Major
-
133
-
-
Issue Summary
This is reproducible on Data Center: (yes)
Root cause here is that issue document is built basing on information stored, for some system fields and custom fields, in thread local caches, that are populated on first read and not reloaded unless they are updated within the same thread.
Known examples of fields that might be affected:
- subtask parent during subtask creation (the parent field of the newly created sub-task might not be indexed correctly, and as a result the sub-task might not show in the Active Sprint page)
- any custom field of date/text type during issue update or creation
Automated operations triggered by issue update events(executed threads parallel than the Issue update thread) might increase frequency of this happening, but in theory all concurrent operations on single issue might be affected.
Steps to Reproduce
- Prepare a project with issues configured to contain at least one simple(text or date type) custom field - cf1
- Create a plugin that performs the following operations on some trigger(rest endpoint, automation)
- operation 1:
- Reads value of cf1 for particular issue issue1
- Consider introducing some sleep here or some debug pause
- Eventually reindexes issue1
- operation 2, triggered separately:
- update value of cf1 in issue1
- reindex issue1
- operation 1:
- Trigger operation1 and operation 2 in a way that operation2 starts after pt 2.1.1 and ends before pt 2.1.3
Expected Results
JQL searches by value set to cf1 in issue1 in pt 2.2.1 return issue1
Actual Results
JQL searches by value set to cf1 in issue1 in pt 2.2.1 do not return issue1
Workaround
Currently there is no known workaround for this behaviour. A workaround will be added here when available
- causes
-
-
- Closed
-
-
-
- Closed
-
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- relates to
-
[JRASERVER-75342] Concurrent modification of single issue might result with stale values of its fields in index
Can we have a update on other data center versions ( Non LTS versions) ?
Hi 7bf9a6d72f38
Unfortunately, this ticket and fix mentioned here is only for Jira DC.
I'm not aware of separate issue tracking for similar problem in Jira Cloud. If you are facing some problems on Jira Cloud, please contact our support. I'm sure they will be able to determine what is the cause and if it can be easily resolved. They will be also able to redirect you to the issue tracking if it is a known problem or create one.
Michał Błajet,
Jira DC Software Engineer
This bug also seems to affect Jira Cloud. Will the fix be deployed to Jira Cloud, or is there a separate issue tracking that?
Dear customers,
Thank you for taking the time to file and comment on this issue.
I’m happy to announce that the fix is ready and it will be available since the the upcoming Jira 9.14.1 release.
According to our policy, after a proper soaking time, we will backport the fix to the LTS versions: 9.4 and 9.12. You can expect it to happen at the beginning of the May this year.
Michał Błajet
Jira DC Software Engineer
We found a second cause for this issue, in addition to this ticket. Via further troubleshooting we determined that the installed version 1.18.6 of the plugin “Multiple Checklists” (https://marketplace.atlassian.com/apps/1220026/multiple-checklists-for-jira?hosting=datacenter&tab=versions) was responsible for causing our issue.
After contacting the plugin vendor and providing information about this bug, they said it was likely related. They also recommended to downgrade to version 1.18.5 (and have since recommended another version, but we are on 1.18.5 now).
After downgrading their plugin, our index issue went away immediately. After our test results were good, we proceeded with the upgrade to 9.4.15. So far, we haven’t encountered any further issues.
Maybe this information helps someone else with the same plugin or another plugin that might also exhibit/trigger bad behavior?
We have this issue when using a scriptrunner Listner which fills in our operator group (custom field) based on the assignee. In some cases the operator group was filled correctly when you look at the ticket, but in our queues in our JSM project the ticket shows up in the wrong queue as it was not indexed properly.
We have this workaround (Jira Server):
1. Create a JQL and save it (in this case: 'Project: updated last 2 minutes')
project = <your projectkey> AND updated >= -2m
2. Create a scriptrunner custom scheduled Job with interval
* * 6-18 ? * MON-FRI
3. Inline script:
def filter = Filters.getMyFilterByName('Project: updated last 2 minutes')
Issues.search(filter).each { issue ->
issue.reindex()
}
https://getsupport.atlassian.com/browse/PS-156689 - The issue also gets resolved if you start background re-indexing and cancel it.
I was referred to this by support. In our environment, if we are bulk creating several sub-tasks, a small percentage of sub-tasks will be missing the parent-link. This lead to inconsistent, and inaccurate search results so as a workaround, we had to start storing the parent ID into a customfield.
Dear customers,
We are pleased to announce that the fix has been backported to Jira LTS versions. The fix will be available in Jira 9.12.9 and Jira 9.4.22, with a planned release date of June 2024.
Sławomir Zaraziński,
Jira DC Software Engineer