-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Low
-
None
-
Affects Version/s: 11.2.0, 11.3.4
-
Component/s: Indexing
-
None
-
11.02
-
1
-
Severity 2 - Major
-
3
Issue Summary
When Jira is configured to use OpenSearch re-indexing fails with an error when immense terms are encountered, in the same way as described in the previously fixed bugs JSWSERVER-20133 and JRASERVER-76392.
Steps to Reproduce
- Configure Jira to use OpenSearch as described in Configuring OpenSearch for Jira.
- Populate an indexed custom field with data greater than 32766 bytes in size.
- Navigate to Administration (⚙) > System > Indexing and perform a re-index.
- In a multi-node cluster, the problem can also be triggered by updating an issue with a custom field value exceeding 32766 bytes in size - the resulting error blocks index replication and causes the cluster nodes to fail to replicate search index changes.
Expected Results
The immense term should be skipped with the following log message:
2026-04-22 12:21:52,367+0000 IssueIndexer:thread-1 ERROR [c.a.j.issue.index.DocumentScrubber] A document contained a potential immense term in field customfield_10400. The field has been removed from the document.
Actual Results
The immense term causes an indexing error:
2026-04-22 13:42:11,328+0000 MultiThreadedIssuesReindexQueueConsumer-4 WARN [c.a.j.s.index.bulk.BatchIssuesReindexQueueConsumer] Failed to update issue: issue/10000
com.atlassian.jira.search.exception.IndexOperationException: Document contains at least one immense term in field="customfield_10400" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104]...', original message: bytes can be at most 32766 in length; got 36000
at com.atlassian.jira.search.opensearch.OpenSearchIndexWriter.mapException(OpenSearchIndexWriter.java:400)
at com.atlassian.jira.search.opensearch.OpenSearchIndexWriter.lambda$validateResponseForErrors$12(OpenSearchIndexWriter.java:357)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
at com.atlassian.jira.search.opensearch.OpenSearchIndexWriter.validateResponseForErrors(OpenSearchIndexWriter.java:359)
at com.atlassian.jira.search.opensearch.OpenSearchIndexWriter.updateBulk(OpenSearchIndexWriter.java:335)
at com.atlassian.jira.search.index.bulk.BatchIssuesReindexQueueConsumer.updateBulk(BatchIssuesReindexQueueConsumer.java:125)
at com.atlassian.jira.search.index.bulk.BatchIssuesReindexQueueConsumer.run(BatchIssuesReindexQueueConsumer.java:89)
at com.atlassian.jira.search.index.bulk.MultiThreadedIssuesReindexQueueConsumer.lambda$start$1(MultiThreadedIssuesReindexQueueConsumer.java:62)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
The indexing error then causes reindexing to fail:
2026-04-22 13:42:11,367+0000 JiraTaskExecutionThread-1 ERROR admin [c.a.j.search.opensearch.OpenSearchIssueIndexManager] Reindex failed due to indexing failure
com.atlassian.jira.index.IndexingFailureException: 1 issue failed to be indexed. This exceeds the fault tolerance limit of 0 (0%).
at com.atlassian.jira.search.opensearch.OpenSearchIssueIndexer.indexIssuesBatchMode(OpenSearchIssueIndexer.java:257)
at com.atlassian.jira.search.opensearch.BlueGreenReindexServiceImpl.doIndexIssuesInBatchMode(BlueGreenReindexServiceImpl.java:171)
at com.atlassian.jira.search.opensearch.BlueGreenReindexStrategy.reindex(BlueGreenReindexStrategy.java:62)
at com.atlassian.jira.search.opensearch.OpenSearchIssueIndexManager.doReindex(OpenSearchIssueIndexManager.java:280)
at com.atlassian.jira.search.opensearch.OpenSearchIssueIndexManager.reIndexAllInternal(OpenSearchIssueIndexManager.java:218)
at com.atlassian.jira.search.opensearch.OpenSearchIssueIndexManager.reIndexIssuesInBackground(OpenSearchIssueIndexManager.java:196)
at com.atlassian.jira.util.index.DefaultCompositeIndexLifecycleManager.reIndexIssuesInBackground(DefaultCompositeIndexLifecycleManager.java:173)
at com.atlassian.jira.web.action.admin.index.ReIndexBackgroundIndexerCommand.doReindex(ReIndexBackgroundIndexerCommand.java:37)
at com.atlassian.jira.web.action.admin.index.AbstractAsyncIndexerCommand.call(AbstractAsyncIndexerCommand.java:63)
at com.atlassian.jira.web.action.admin.index.ReIndexBackgroundIndexerCommand.call(ReIndexBackgroundIndexerCommand.java:19)
at com.atlassian.jira.web.action.admin.index.AbstractAsyncIndexerCommand.call(AbstractAsyncIndexerCommand.java:26)
at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:536)
at com.atlassian.jira.task.TaskManagerImpl$TaskCallableDecorator.call(TaskManagerImpl.java:494)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at com.atlassian.jira.task.ForkedThreadExecutor$ForkedRunnableDecorator.run(ForkedThreadExecutor.java:216)
at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: com.atlassian.jira.search.index.bulk.exception.FaultToleranceLimitExceededException: 1 issue failed to be indexed. This exceeds the fault tolerance limit of 0 (0%).
at com.atlassian.jira.search.index.bulk.DefaultBulkIssueIndexer.validateAsyncResult(DefaultBulkIssueIndexer.java:175)
at com.atlassian.jira.search.index.bulk.DefaultBulkIssueIndexer.reindexAllIssues(DefaultBulkIssueIndexer.java:119)
at com.atlassian.jira.search.opensearch.OpenSearchIssueIndexer.indexIssuesBatchMode(OpenSearchIssueIndexer.java:250)
... 17 more
In a multi-node cluster, when an issue containing an immense term is updated the problem occurs during index replication, which blocks processing of the index replication queue and causes all nodes to fall behind on index replication:
2026-04-24 08:08:05,096+0000 Caesium-1-4 WARN anonymous [c.a.j.search.opensearch.OpenSearchIndexWriter] Bad request for item ID issue/10000: Document contains at least one immense term in field="customfield_10400" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104]...', original message: bytes can be at most 32766 in length; got 36000
2026-04-24 08:08:05,096+0000 Caesium-1-4 ERROR anonymous [c.a.j.s.index.rio.AbstractReplicatedIndexOperationService$IndexRequestsBatcher] Failed to apply batch of 5 update requests to index
2026-04-24 08:08:05,097+0000 Caesium-1-4 ERROR anonymous [c.a.j.s.index.rio.OpenSearchIndexReplayJob] An error occurred while replaying the index to OpenSearch index
com.atlassian.jira.search.exception.BulkIndexOperationsException: Bulk index operation failed, on documents {issue/10000=com.atlassian.jira.search.exception.IndexOperationException: Document contains at least one immense term in field="customfield_10400" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: '[109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104, 109, 101, 104]...', original message: bytes can be at most 32766 in length; got 36000}
at com.atlassian.jira.search.opensearch.OpenSearchIndexWriter.validateResponseForErrors(OpenSearchIndexWriter.java:365)
at com.atlassian.jira.search.opensearch.OpenSearchIndexWriter.updateBulk(OpenSearchIndexWriter.java:335)
at com.atlassian.jira.search.opensearch.consistency.ReadYourWritesIndexWriter.updateBulk(ReadYourWritesIndexWriter.java:56)
at com.atlassian.jira.search.index.rio.AbstractReplicatedIndexOperationService$IndexRequestsBatcher.drainSingleUpdateRequestsBatch(AbstractReplicatedIndexOperationService.java:194)
at com.atlassian.jira.search.index.rio.AbstractReplicatedIndexOperationService$IndexRequestsBatcher.processRequests(AbstractReplicatedIndexOperationService.java:175)
at com.atlassian.jira.search.index.rio.AbstractReplicatedIndexOperationService.applyOperationsToIndex(AbstractReplicatedIndexOperationService.java:126)
at com.atlassian.jira.search.index.rio.BaseRioTransaction.replayInternal(BaseRioTransaction.java:111)
at com.atlassian.jira.search.index.rio.BaseRioTransaction.replay(BaseRioTransaction.java:76)
at com.atlassian.jira.search.index.rio.ClusterSynchronisedIndexReplayStrategy.replay(ClusterSynchronisedIndexReplayStrategy.java:21)
at com.atlassian.jira.search.index.rio.OpenSearchIndexReplayJob.runJob(OpenSearchIndexReplayJob.java:33)
at com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:145)
at com.atlassian.scheduler.core.JobLauncher.launchAndBuildResponse(JobLauncher.java:117)
at com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:99)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.launchJob(CaesiumSchedulerService.java:464)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJob(CaesiumSchedulerService.java:459)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJobWithRecoveryGuard(CaesiumSchedulerService.java:483)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeQueuedJob(CaesiumSchedulerService.java:411)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeJob(SchedulerQueueWorker.java:66)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeNextJob(SchedulerQueueWorker.java:60)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.run(SchedulerQueueWorker.java:35)
at java.base/java.lang.Thread.run(Thread.java:1583)
Workaround
As a partial workaround, the Administration (⚙) > System > Indexing > OpenSearch Indexing Configuration > Indexing fault tolerance percentage can be increased to allow indexing to complete successfully. However, the issues containing immense terms will be excluded from the index and so will not be searchable.
If excluding the problematic issues from the database is unacceptable, then it will be necessary to truncate, disable or delete the problematic field as described in the knowledge base article Indexing fails due to immense field.