Community resources
Community resources
Community resources
- Community
- Q&A
- Confluence
- Questions
- Tasks are only updated when the site is manually reindexed
Tasks are only updated when the site is manually reindexed
Hello everyone,
I'm having an issue with Confluence. We're using version 10.2.7 of the Datacenter edition.
We recently updated from 9.2.9 to 10.2.7. Since the update, tasks are no longer syncing. When a task is created on a page, it no longer appears on the Tasks page in the personal area.
The task only reappears after a site reindex. After that, tasks show up for a few hours (approximately), and then synchronization stops working again until the next site reindex.
I’ve already tried clearing the cache, but that didn’t fix the problem.
Does anyone know if this is a known bug?
I couldn’t find any mention of this issue in the release notes.
Best regards, Bernd
3 answers
Hello @Arkadiusz Wroblewski @Christos Markoulatos -Relational-
I have a few indexing logs for you here:
2026-04-07 03:00:00,098 WARN [Caesium-1-4] [index.lucene.snapshot.DefaultLuceneIndexSnapshotManager] findForJournal Error iterating snapshot directory: C:\\Program Files\\Atlassian\\Application Data\\Confluence\\shared-home\\index-snapshots
2026-04-07 07:53:04,795 WARN [Caesium-1-4] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [6836011] has reached the maximum try times (3), skipping it
2026-04-16 03:00:00,027 WARN [Caesium-1-2] [index.lucene.snapshot.DefaultLuceneIndexSnapshotManager] findForJournal Error iterating snapshot directory: C:\\Program Files\\Atlassian\\Application Data\\Confluence\\shared-home\\index-snapshots
2026-04-16 03:00:00,028 WARN [Caesium-1-2] [index.lucene.snapshot.DefaultLuceneIndexSnapshotManager] findForJournal Error iterating snapshot directory: C:\\Program Files\\Atlassian\\Application Data\\Confluence\\shared-home\\index-snapshots
2026-04-16 11:34:52,884 WARN [Caesium-1-3] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590301] has reached the maximum try times (3), skipping it
2026-04-16 11:43:13,047 WARN [Caesium-1-4] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590440] has reached the maximum try times (3), skipping it
2026-04-16 11:45:53,072 WARN [Caesium-1-1] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590456] has reached the maximum try times (3), skipping it
2026-04-16 11:47:13,092 WARN [Caesium-1-2] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590482] has reached the maximum try times (3), skipping it
2026-04-16 11:48:53,181 WARN [Caesium-1-3] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590494] has reached the maximum try times (3), skipping it
2026-04-16 11:49:28,293 WARN [Caesium-1-1] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590503] has reached the maximum try times (3), skipping it
2026-04-16 11:53:18,286 WARN [Caesium-1-4] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590515] has reached the maximum try times (3), skipping it
2026-04-16 11:53:43,292 WARN [Caesium-1-4] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590526] has reached the maximum try times (3), skipping it
2026-04-16 12:00:23,510 WARN [Caesium-1-3] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590565] has reached the maximum try times (3), skipping it
2026-04-16 12:01:33,534 WARN [Caesium-1-3] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590608] has reached the maximum try times (3), skipping it
2026-04-16 12:02:03,543 WARN [Caesium-1-1] [confluence.impl.journal.DefaultJournalManager] handleFailedEntry Entry in journal [task_report_index] with ID [7590622] has reached the maximum try times (3), skipping it
The warning message keeps repeating.
We use Microsoft SQL Server as our SQL server.
I hope this helps.
Best regards, Bernd
Hi @Bernd Kruse
With a quick look
The task_report_index journal is repeatedly failing to process new task entries, hitting the 3-retry limit and skipping them entirely. That's exactly why tasks disappear over time every new task that gets skipped is simply never indexed. The separate findForJournal error on the snapshot directory is also worth noting, as it suggests Confluence is having trouble reading the index snapshot directory on that node, which may be contributing to the journal failures.
The key question now is why those journal entries are failing. The logs tell us they're being skipped, but not the underlying cause. To get to the root of it, could you check the atlassian-confluence-index.log (or atlassian-confluence.log) around the same timestamps specifically around 03:00 on April 7th and April 16th for any ERROR lines that appear just before or alongside those handleFailedEntry warnings? There's likely a stack trace or exception hiding nearby that will tell us exactly what's going wrong when Confluence tries to process those task journal entries.
In the meantime, the snapshot directory error (C:\Program Files\Atlassian\Application Data\Confluence\shared-home\index-snapshots) is worth checking too confirm that the Confluence service account has full read/write permissions to that path, as a permission or file lock issue there could cascade into the journal processing failures you're seeing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I reviewed the logs in the atlassian-confluence-index.log. There are no errors on the 7th, aside from the messages I’ve already sent you. I also can’t find any additional entries on the 16th. The other entries worth noting are the reindexes I performed. These completed 100%.
In the atlassian-confluence.log, I can find the following logs around 3 a.m.:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Bernd Kruse
post-upgrade indexing jobs or queue processing Problem probably.
What saying indexing logs ? Can you paste them here ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It will be more helpful when you answer under a posts from us directly.
I know dumb question but did you done snapshot prior to update and can Fall back and try Update again ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ich habe vor dem Update einen Snapshot gemacht. Allerdings ist dieser Fehler erst später aufgetaucht und daher ist der Snapshot schon wieder gelöscht worden. Wir können daher das Update nicht noch einmal durchführen.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Die entscheidende Meldung ist für mich nicht die Snapshot-Warnung, sondern das hier:
task_report_index ... has reached the maximum try times (3), skipping it
Das heißt, Confluence versucht die Task-Index-Updates im Hintergrund zu verarbeiten, scheitert dabei drei Mal und überspringt den Eintrag dann. Genau das passt auch zu deinem Verhalten: ein manueller Reindex baut den Index neu auf, danach funktioniert es kurz, und später fehlen neue Änderungen wieder.
Da ihr SQL Server nutzt, ist das auch nicht der MySQL-Bug, der vorher genannt wurde.
Der nächste Schritt ist deshalb, die eigentliche Exception vor dieser WARN-Meldung zu finden. Die von dir gepostete Zeile ist nur das Endergebnis nach drei Fehlversuchen, nicht die eigentliche Ursache.
Ich würde das Logging für com.atlassian.confluence.plugins.tasklist.report.searchindex auf TRACE stellen und dann noch einmal prüfen, welcher ERROR oder Stacktrace direkt davor auftaucht.
So wie es aussieht, ist das also kein allgemeines Reindex-Problem, sondern ein Fehler in der laufenden Verarbeitung des Task-Indexes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Bernd Kruse
Hi Bernd! I did some digging and found a potentially related bug. Confluence introduced a Task Report Index in version 8.7, a separate index specifically for tasks used to power the personal Tasks view. There's a known issue ([CONFSERVER-99388] Task Report Macro not showing all tasks in Confluence when connected to MySQL database - Create and track feature requests for Atlassian products.) where this index fails to rebuild correctly after the first iteration, which would explain your symptoms: a full site reindex temporarily restores things by rebuilding the Task Report Index from scratch, but it then degrades again as new tasks come in. Quick question though, what database are you running Confluence on? The specific bug report is tied to MySQL, so knowing your DB type will help confirm whether this is the same root cause or something slightly different. Either way, it's worth checking General Configuration → Content Indexing → Queue Contents after a reindex to see if the queue stops being processed after a few hours, and looking in atlassian-confluence-index.log for any LuceneIndexFlusher ABORTED warnings, that would help narrow it down further!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.