-
Bug
-
Resolution: Tracked Elsewhere
-
High
-
None
-
5.3.3, 5.4.6
-
11
-
Severity 2 - Major
-
56
-
Issue Summary
When an Automation rule (from Automation For Jira) is used to update a custom field in a ticket from a JSM project, the custom field value is not always indexed, as a result any feature relying on issue search does not show up to date information such as:
- Issue Filters
- JSM queues
Root Cause
When a field is updated by an Automation rule, the data in the database is correctly updated but intermittently the reindexing does not occur and due to that the JSM queue breaks and gives incorrect results. A custom field is updated correctly in the Database
This is not seen when the field is manually updated but only occurs when using the Automation rule to update the field.
SdSerialisedOffThreadProcessor:thread-4 runs AsyncMessageProcessorImpl#masterQueueSpinConsumer, processing events that are added after it has started. The loop runs without refreshing its thread local caches when necessary and due to that the indexes are not properly updated which causes the issue.
This is reproducible on Data Center: yes
Steps to Reproduce
- Customer uses A4J to update the Select List (single choice) customfield to
- “Customer” after a JSM customer adds a comment
- “Agent ” after a JSM agent adds a comment
- Customer has a JSM queue that uses this customfield value in the queue JQL query to track tickets waiting on support.
- Once the tickets come into this queue then agents respond to the customer
Expected Results
Everything works as expected and whenever the custom field is updated then the tickets are correctly seen in the queue and helps the agents to work on it.
Actual Results
This issue occurs intermittently sometimes even after the custom field data is properly updated still the JQL query results are incorrect and due to that the JSM queue does not have the correct tickets which causes a lot of problems for the users to track the tickets.
Workaround
To be added later
- is caused by
-
-
- Closed
-
[JSDSERVER-12625] Updating a customfield using Automation for Jira does not always initiate proper reindexing which affects the queue and issue filters
In our case It causes issues when you when you use a behaviour script to update field Operator group based on field Assignee. This will result in false results in the dashboard of several operator groups.
Thanks @alex_cooksey, it was support who pointed out to this issue as the root of our particular issue (we're already in contact with them, for our customer, but under a different user account, because one of my colleages is the main role in charge of solving this)
Have a great day,
Luismi
Hi 267e18578293,
Are you able to contact our support team regarding your issue and reference this bug? You can reach out at https://support.atlassian.com/contact/
We're keen to work with an affected customer to reproduce the issue internally & test a possible workaround.
The problem is yet to be addressed in a newer version, as yet. But we're hoping to have it resolved shortly - however would love to work with an affected customer to do so.
Thanks so much,
Alex
We are also affected by this issue that compromises data integrity.
Fields processed by the automation rule are not indexed correctly, so issues are not visible in the dashboards for the users who should solve these issues, because we use these fields to assign issues to groups or individuals.
Please:
1) provide a workaround (if available)
2) raise the priority of this bug
3) confirm the issue is solved (or not) in higher versions (does a version upgrade solve this issue)
I don't know, but as we're initialising groups in this field, at the very least, we'd have to create a false group and modify all our queues (and linked boards) until you resolve the problem. Given that we have another workaround, I'd rather not push this solution and we'll wait for you to resolve the problem definitively.
Hi 402650d91b71
Thank you for the details, I will investigate further.
Geven that the bug only occurs when the custom field has not been set, a possible workaround may be to set a default for the Custom field, although I am not sure this will work with your use case.
My answers :
- Yes
- This doesn't solve the problem. The queues that display tickets in error continue to display them after refreshing the browser.
- We have more of a problem with tickets appearing in excess. In any case, if I run a simple query that looks for tickets where the field in error is empty, the tickets appear while we see that the field's column has a value displayed.
- I can't recreate the automation identically in the legacy automation because we don't have the same condition available. But by testing with another, the field value set does not present the problem.
For information, the problem only occurs when the field is empty at the start. If the automation runs again when a value is already present in the field, then the bug doesn't occur. We have shared some details in a Atlassian ticket GHS-264724.
As a workaround for the moment, we're asking our agents to do as usual so that the automation runs, then to delete the data in the bugged field, then to save, then to re-enter the data manually and save. And then the field value no longer has any bugs. The bug only occurs when it's the automation that sets a value and it's the first one.
Hi 402650d91b71 and cd0c5731febb
I am a developer investigating this issue, I just have a few questions to try and narrow down what is causing this.
- Can you see the incorrect custom field value when you view the ticket directly?
- What happens when you refresh the browser window showing the queue, does it remain in the incorrect state?
- If you query with JQL directly off the Jira Search screen, does the missing issue show up?
- If we use Servicedesk Legacy Automation, does that behave any differently? See the example image of a "Legacy Automation" rule to try
We are also affected by this problem, that fields which are processed by an automation rule are not indexed correctly. In our case, this even leads to the fact that such issues are not visible for the users who should edit the issues, because we use the corresponding field for the "Browse project" permission.
To put it in a nutshell: The data integrity is corrupted because the field values from the database and the cache do not match. And this with an LTS version (9.4.8).
Hi all,
The behaviour described in this bug report is caused by an issue with Jira Server - "
JRASERVER-75342- Concurrent modification of single issue might result with stale values of its fields in index"We've worked with the Jira team on diagnosing and reproducing this problem - and the Jira team have committed to fix this problem shortly.
However to set expectations - I don't imagine this fix will be resolved before 9.13 / 5.13 Code Freeze and subsequent release in early December - so will be targeting a fix for early 2024.
Please follow the Jira Server bug report linked above for future updates from the team on their release.
Thanks for your understanding,
Alex
Jira Service Management