Process Variables are getting mixed up between Process Instances

I’m running Camunda community edition with config as below. There are around 3000+ open/active process instances that are started up everyday, and an average of around 15000 open instances at the end of each day. I’m seeing intermittent issues where some of the process variables are getting mixed up between process instances randomly. This includes some variables which are only initialized once at the time of instance start and are never edited/updated again, which rules out application issues. This is happening across all Process Definitions in the system, and most times the “bad” variables in a Process Instance are actually from a Process Instance under a different Process Definition. I’m at a loss to figure out what is going on. Any idea what could be causing it or what angle I should look at it from?

camunda.bpm.history-level=AUDIT
camunda.bpm.database.schema-update=false
camunda.bpm.database.table-prefix=bpm.
camunda.bpm.database.schema-name=bpm
camunda.bpm.job-execution.core-pool-size=10
camunda.bpm.job-execution.max-pool-size=100
camunda.bpm.job-execution.max-jobs-per-acquisition=10
camunda.bpm.metrics.enabled=true
camunda.bpm.metrics.db-reporter-activate=true

@charanya Which database are you using? What is the isolation level set for the database transactions?

Are you doing concurrent operations using java api’s like CompletableFuture/ParallelStreams to start instance/complete task/update task?

I’m using Postgres 11. Std transaction isolation of ‘read committed’. I’m not using any concurrent ops java apis, but task updates & task completions are done on multiple-threads via camunda REST api. Instance start happens on a single thread only, also via REST.

thanks for the awesome information.

We did not experience this issue yet. Needs much debugging in that case, could you provide minimal github project link to replicate this issue.

I can confirm as well. The executionId from a task returned here:

/engine-rest/variable-instance?processInstanceIdIn=

will actually be the taskId, and the taskId will be null for a live task.