Problematic behavior of optimistic locking in Camunda and the RollbackPostProcessor

We are observing faulty behavior in our application that leads to the display of zombie documents.

According to our analysis, the following could be the cause of the problem:

We are using the data-service component in conjunction with workflows. Due to a double-click in the UI, two COMPLETE_TASK calls are triggered in quick succession.
Thread 1 and Thread 2 begin working on the same process instance and attempt to complete the same task. At the beginning of their transactions (almost simultaneously), both store the Solr index state.

Camunda uses optimistic locking, meaning two threads cannot complete the same task concurrently (only one can succeed).
Thread 1 completes successfully, commits to the database, and updates the Solr index.
Thread 2 (Transaction 2) fails due to optimistic locking (standard Camunda behavior), after which the RollbackPostProcessor is executed.

While the database changes remain persistent, the search index is left in a vulnerable state. The RollbackPostProcessor resets it to an older state — the state prior to both transactions. As a result, the index becomes corrupted. The application can only be recovered by performing a reindex.

Created a ticket to investigate this issue (A12S-6630).

This was determined a Bug which will be resolved in 2026.06.
The RollbackPostProcessor will be removed and index updates now use JDBC within the same transaction. Index updates now participate in same JDBC transaction as document updates.

Thx @patrick-long-drift!

Is it possible for MGM to deliver the fix in a patch for version 2025.06?

Hi @mathias-early-ravine ,

This behavior is already resolved for versions 2025.06 and future 2026.06 because it was caused by Solr synchronization code. This code was removed in DS version 38.0.0 (A12 version 2025.06), If you still have synchronization issues in this version, it cannot be caused by Solr synchronization. Which DS (A12 version) are you using?