What's changed in Jira after the implementation of indexing limits
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
Server* 製品のサポートは 2024 年 2 月 15 日をもって終了します。Server 製品を利用している場合は、Atlassian Server のサポート終了のお知らせページにて移行オプションをご確認ください。
*Fisheye および Crucible は除く
JRASERVER-73874 - 課題詳細を取得中... ステータス
Since Jira 8.22.2 (backported to 8.20.12), we’ve changed how we create indexes for issue-related entities - find out more here on why and what has been changed: Safeguards in Jira DC index
This article answers some common questions related to Jira indexing limits and explains differences in the way Jira works since the update. For more information about the updates, see Introducing safeguards to Jira index.
This section features common indexing-related questions for users with admin rights. If you don't have Jira admin permissions, skip to the next section.
Can I manually reindex a comment, worklog, or change?
rest/api/2/reindex/issue endpoint allows reindexing the whole issue, optionally including worklogs, comments, and changes by specifying query params for the request.
However, this endpoint doesn’t remove old indexes. If the parameters for including comments, worklogs, or changes are set to
true, the most recent entities of issue will be reindexed, and old indexes for the rest of the entities will remain.
Example request to trigger issue reindex:
Why can't I search for more comments, worklogs, or changes than the limit is set?
When an issue is modified by changing some field or by adding a comment, all indexes related to this issue are updated, but not all of them are rebuilt. Even if there are more entities than what's set in the limit’s properties, adding a new comment doesn’t cause removing already created indexes for older comments. Because of this, older comments can be searched.
This behavior should not be something to rely on since these older comments won’t be searchable after full foreground reindex.
I need to search for more comments, worklogs, and changes. Can I disable the limit for one particular type of entities?
You can set the limit value for each type of issue-related entities independently or turn off the limiting at all. For example, if there is a need to have all changes indexed for reports, you can turn it off using suitable property and keep indexing limits on comments and worklogs.
Switching off the limiting or setting the value too high can adversely affect the condition of your Jira instance. Be cautious when doing such changes considering the risks involved.
Use the following properties to manage the indexing limit:
jira.safeguards.indexing.issue.changelogsfor change history groups
The index limiting feature can be turned off for each entity type individually by setting the system property to -1.
Why doesn't the updatedBy JQL function return expected issues?
Since 8.22.3, we have modified the list of fields whose changes will be indexed. As the updatedBy function uses indexes to search for issues, now it can return issues that have one of the following fields changed by a user from the query:
Currently, there is no easy functionality to add specific fields to be included in indexes. However, this behavior can be turned off by setting the
jira.safeguards.indexing.issue.changelogs.do.not.filter.out.unsupported.fields property to
true. Following this change, all fields will be included in change history indexes.
There is a plan to introduce a user-friendly way of managing fields whose changes should be included in change history indexes. You can check the status of it via this link: JSWSERVER-21346.
I don’t want to index given entity types at all. Can I turn off indexing for this particular type?
Yes, you can turn it off by setting the property responsible for managing the related indexing limit to 0. But be aware that indexes are also used by an external app installed in the Jira instance, which can cause some problems.
Why does searching return a result that is not present in Jira at all?
When some action could be made not in Jira (for example, manipulating data in the database), indexes might be updated improperly or not updated at all. This can lead to situations when some data is modified or removed, but the indexes related to old data will still be present in Jira. Since searchers use indexes, it can cause some unexpected results.
Why can’t I search for a comment even if it's visible in an issue?
Searchers are using indexes to get faster responses, and since we are indexing just a subset (1000) of the latest comments, worklogs, and changes, some of them are not searchable. It doesn’t mean that they are removed—these entities are in the database, and you can access them, for example, in the issue view.
How can I make a non-indexed comment searchable?
When Jira generates an index, it gets the subset of the most recent updated comments and worklogs. In a case when some of the older comments are important to be searchable, the workaround is to update this comment.
Why do some reports look different than expected compared to the previous Jira version?
Some of the reports may use indexes to display some information. For example, Jira Software has the following reports:
Release Burndown Chart
Version Progress Chart
Cumulative Flow Chart
These reports use indexes of changes made on the status field and the
fix version field. Since indexes now contain fewer entities, reports will display information based on a smaller amount of data.