Problem

In Confluence environments with OpenSearch enabled, the journal state is persisted in OpenSearch via the OpenSearchJournalStateStore. After truncating the journalentry table and restarting the application (e.g., during a Blue-Green reindex), Confluence continues to regenerate previously processed journal entries based on the stored journal pointer in OpenSearch.

This behavior causes millions of unnecessary journal entries to be re-enqueued, even though the actual content and permission changes have already been fully indexed. The system lacks a supported or documented method to update or reset the "last processed journal ID" in OpenSearch, leading to severe and prolonged database load in large-scale environments.

Suggested Solution

Some potential improvements to consider:

• Provide a supported admin API or system-level tool to manually reset the journal pointer in OpenSearch (`OpenSearchJournalStateStore`)
• Allow administrators to align or override the stored journal ID after a full site reindex or maintenance window
• Improve journal regeneration behavior by detecting duplicate or redundant entries already covered by a recent reindex

Why This Is Important

Large Confluence Data Center customers performing bulk permission or restriction changes (via API or scripting) can generate tens of millions of journal entries. These entries continue to regenerate after reindexing due to the stale journal pointer in OpenSearch.

The resulting DB pressure impacts overall Confluence performance, delays indexing, and creates operational risks, especially when large updates are mandated by compliance or policy.

Customers with OpenSearch enabled currently have no supported workaround for resetting this pointer unless they implement a custom OpenSearch client integration — which is not feasible in all environments.

Workaround

There is no supported workaround to reset the journal pointer stored in OpenSearch.

While it's possible to truncate the journalentry table and restart Confluence, the journal entries will regenerate unless the OpenSearch journal state is updated as well.

The only theoretical workaround would involve using the OpenSearch API to manually update the journal index document that stores the last processed ID. However, this is undocumented, unsupported, and may introduce risks if not done carefully.