Cluster nodes can concurrently process the same permission-reindex batch, creating duplicate journal entries

XMLWordPrintable

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Medium
    • None
    • Affects Version/s: 10.2.18, 10.2.19
    • None
    • 4
    • Severity 3 - Minor
    • 52

      Issue Summary

      Out of the box, ContentTreePermissionReindexEventBackgroundSender->process() processes 20 page ids in each batch execution.

      When the processing of this batch runs for a long time, other Confluence nodes can potentially also run ContentTreePermissionReindexEventBackgroundSender->process() and process the exact same pageIdsToProcess from background_job row.

      This can result in redundant duplicate data set added into journal_entry table.

      Steps to Reproduce

      1. Install a clustered Confluence instance with multiple nodes
      2. Setup a data set with the following structure:
      3. Create a new "Base Page"
      4. Directly under Base Page
        • Page1 (800 pages directly under this)
          • Under one of the new child pages, create a deep page tree of 1200 pages deep
        • Page2 (800 pages directly under this)
          • Under one of the new child pages, create a deep page tree of 1200 pages deep
        • Page3 (800 pages directly under this)
          • Under one of the new child pages, create a deep page tree of 1200 pages deep
      5. Every single page above should have 1000's of comments added to the page
      6. The aim is to create a large enough data set so that ContentTreePermissionReindexEventBackgroundSender->process() processing of the default 20 page ids takes a long time.
      7. Change the permission on Base Page
        • This will result in a ContentTreePermissionReindexEventBackgroundSender added to table background_job

      For a long running batch run ContentTreePermissionReindexEventBackgroundSender->process(), processing 20 page ids:

      Expected Results

      Multiple nodes do not process the same pageIdsToProcess from background_job for the same background_job.id.

      Actual Results

      Multiple nodes process the same pageIdsToProcess from background_job for the same background_job.id.

      This can result in each node adding redundant duplicate data set added into journalentry table.

      Manually adding DEBUG to getPortionOfPageIds across each node will show the same IDs processed across each node.

      e.g.
      NODE 1

      2026-10-12 01:54:01.654 [Caesium-1-2] confluencelocalmsb-0 [BYTEMAN] getPortionOfPageIds - IDs selected for this batch (20 items): [163933, 163934, 165268, 165424, 165473, 165630, 166932, 168712, 168872, 168928, 169029, 171898, 175432, 178945, 182493, 186162, 189878, 193407, 1081796, 1085489]
      

      NODE 2

      2026-10-12 01:56:24.529 [Caesium-1-2] confluencelocalmsb-1 [BYTEMAN] getPortionOfPageIds - IDs selected for this batch (20 items): [163933, 163934, 165268, 165424, 165473, 165630, 166932, 168712, 168872, 168928, 169029, 171898, 175432, 178945, 182493, 186162, 189878, 193407, 1081796, 1085489]
      

      Workaround

      Currently there is no known workaround for this behavior.

              Assignee:
              Unassigned
              Reporter:
              Eric L
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated: