Environment (Required on creation):

Tested with spring boot and camunda-assert.
Introduced in version 7.15.

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

We observed that if a process is started from a task that has input/output variables defined then the variables in the process are transformed into concurrent local and their execution id changes.

Steps to reproduce (Required on creation):

There is an example in the support ticket SUPPORT-13241.

In order to reproduce this define a variable in the process start and have a user task with input/output parameters. Start a new process instance before this user task with startBeforeActivity.
The previously defined variable will end up being concurrentLocal and the execution id will be different than the process instance id.

The variable won't be concurrentLocal and the execution id remains the process instance id if:

• the process is started normally from the very beginning.
• the user task doesn't have input/output parameters defined.

Observed Behavior (Required on creation):

The variable is concurrent local and the execution id is not the process instance id.

Expected behavior (Required on creation):

The variable is not concurrent local and the execution id is the process instance id.

Root Cause (Required on prioritization):

The behaviour changed in v7.15 due to another bug fix (CAM-12656) but it's not the root cause. The change that this introduced was that the setActivity(null) happens after the start of the process. Which makes the check for concurrent local (PvmExecutionImpl#isExecutingScopeLeafActivity) to be true. But only if the task had input/output parameters defined. When a task has input/output parameters defined then the activity gets turned into a scope (org.camunda.bpm.engine.impl.pvm.process.ActivityImpl#setScope).

The combination of these two things cause the variable to end up concurrent local.

Solution Ideas (Optional):

We came to a conclusion that adding an extra condition in the PvmExecutionImpl#isExecutingScopeLeafActivity to check if the execution is not the process instance (execution.getParent() != null) would solve this issue and still work with all the other use-cases.
There is a PR to demonstrate this: https://github.com/camunda/camunda-bpm-platform/pull/1855

Hints (optional):