Issue Summary

Task Report Macro not showing all tasks in Confluence when connected to MySQL database.

Task Report Index is introduced in Confluence 8.7 which should index all task lists in Confluence to serve Task Report Macro.
However, when Confluence is relying on Task Report Index in an instance connected to MySQL database, the Task Report Macro can be inaccurate when the total number of tasks in Confluence is more than 1000.

This is reproducible on Data Center: yes

Environment

• Confluence 9.1.0
• MySQL 8.2

  mysql> select VERSION();
  +-----------+
  | VERSION() |
  +-----------+
  | 8.2.0     |
  +-----------+
  1 row in set (0.00 sec)
  

• Having more than 1000 task lists in AO_BAF3AA_AOINLINE_TASK table

  mysql> select count(*) from AO_BAF3AA_AOINLINE_TASK;
  +----------+
  | count(*) |
  +----------+
  |   318019 |
  +----------+
  1 row in set (0.03 sec)
  

Steps to Reproduce

1. Install Confluence 9.1.0 and connect it with a supported MySQL version
2. Create more than 1000 Task Lists
3. Insert a Task Report Macro onto a page that is configured to show all tasks (which is more than 1000 that were created from the step above)

Expected Results

Task Report Macro shows all tasks that satisfy the macro condition

Actual Results

Not all tasks that satisfy the macro condition is shown.

Diagnostic

This is because a bug in the SQL query Confluence sends to MySQL fails to retrieve tasks after the first iteration when building Task Report Index. The steps below can help to verify the issue:

1. Go to General Configuration > Logging and Profiling
   • Search for com.atlassian.confluence.plugins.tasklist.report.searchindex and set it to TRACE level
   • Scroll to the bottom and click Save
2. Go to General Configuration > Content Indexing
   • Click Rebuild for Site reindex option, which will also trigger a rebuild for Task Report Index
     Please note that rebuilding site index may take a long time depends on the size of Confluence. Only perform this in a non-production environment as diagnostic step
3. Pay attention to the atlassian-confluence.log with the logging below:

   2025-03-06 14:46:50,737 DEBUG [Caesium-1-1] [report.searchindex.indexmanagement.FullReIndexer] removeAllDocuments All documents in the search index have been removed.
   2025-03-06 14:46:50,738 TRACE [pool-17-thread-2] [report.searchindex.indexmanagement.FullReIndexer] indexNextBatchOfInlineTasks Starting iteration 0 of indexing tasks
   2025-03-06 14:46:50,752 TRACE [pool-17-thread-2] [report.searchindex.indexmanagement.FullReIndexer] indexNextBatchOfInlineTasks 1000 tasks retrieved from the DB on iteration 0. Indexing them.
   2025-03-06 14:46:50,752 TRACE [pool-17-thread-2] [report.searchindex.indexmanagement.FullReIndexer] indexNextBatchOfInlineTasks Found 6 unique content ids for 1000 inline tasks on iteration 0
   2025-03-06 14:46:50,752 DEBUG [pool-17-thread-2] [report.searchindex.indexmanagement.FullReIndexer] getAddSearchDocumentAction Creating a document for content id 163915 and task AO_BAF3AA_AOINLINE_TASK {GLOBAL_ID = 1}
   2025-03-06 14:46:50,793 DEBUG [pool-17-thread-2] [report.searchindex.indexmanagement.FullReIndexer] getAddSearchDocumentAction Creating a document for content id 1507329 and task AO_BAF3AA_AOINLINE_TASK {GLOBAL_ID = 24}
   ...
   2025-03-06 14:46:51,023 TRACE [pool-17-thread-2] [report.searchindex.indexmanagement.FullReIndexer] indexNextBatchOfInlineTasks Finished iteration 0 containing 1000 inline tasks Last processed global task id: 1004. Duration: 00:00:00.271
   2025-03-06 14:46:51,024 TRACE [pool-17-thread-2] [report.searchindex.indexmanagement.FullReIndexer] indexNextBatchOfInlineTasks Starting iteration 1 of indexing tasks
   2025-03-06 14:46:51,025 DEBUG [pool-17-thread-2] [report.searchindex.indexmanagement.FullReIndexer] indexNextBatchOfInlineTasks No more tasks were found on iteration 1
   2025-03-06 14:46:51,025 INFO [Caesium-1-1] [report.searchindex.indexmanagement.FullReIndexer] reindexAllTasks Full inline tasks reindexing (for Task Report macro) has been finished. Processed 1000 inline tasks. Duration: 00:00:00.304. In average, 1000 inline tasks were processed in 304 ms.
   2025-03-06 14:46:51,025 DEBUG [Caesium-1-1] [report.searchindex.indexmanagement.TaskReportIndexPersistedStateService] markAsReady Task report index is going to be marked as ready. All task report macros will use search index to retrieve tasks.
   2025-03-06 14:46:51,025 INFO [Caesium-1-1] [report.searchindex.indexmanagement.TaskReportIndexPersistedStateService] markAsReady Task report index was marked as ready. All task report macros will use search index to retrieve tasks (they will be rendered very fast).
   2025-03-06 14:46:51,026 TRACE [Caesium-1-1] [searchindex.indexmanagement.indexqueue.IndexQueueProcessorImpl] flushQueue Inline task index job flushed 0 tasks. Duration: 00:00:00.311
   

   Notice that Confluence would only index the first iteration where the default batch size is set to 1000, and incorrectly report "No more tasks were found" on the next iteration despite there are more tasks in the database.

Workaround

As a workaround, customer can include a Dark Feature to force Confluence to always retrieve the Task Lists from the database instead of relying on the incorrect Task Report Index:

1. Go to the URL below with an admin account:
   • <BaseURL>/admin/darkfeatures.action
2. Scroll down to the Site Dark Features and enter the following feature in the empty field:

   confluence.task-report.use-database-for-reports
   

   • Click Submit

Once this issue is fixed in the future release, please manually remove the Dark Feature flag above to restore the usage of Task Report Index