Hey robert.emsbach,

thanks a lot for putting that into a ticket here and for adding a test case as well, that is very helpful to us!

I will move it on to decision-making since tassilo.weidner already confirmed it's potentially a bug.

Best,
Tobias

Thanks for raising the ticket. I understand the problem, but I think the solution proposal is not right: The task id reference is used to for variables that are set in the task scope (confer the second picture at https://docs.camunda.org/manual/7.14/user-guide/process-engine/variables/#variable-scopes-and-variable-visibility). Accordingly, APIs like TaskService#getVariablesLocal return those variables.

The multi-instance element variable is set in the execution scope that runs the task, i.e. one level higher. It is not a task-local variable. For a simple multi-instance user task, this may not make too much sense. But it generalizes nicely for multi-instance subprocesses, where the element variable is also set on the scope of the topmost execution that represents that part of the execution tree (so that it is visible to all deeper scopes).

Based on this, I do not consider this a bug of the task query API. It was never designed to evaluate the hierarchy of variables. As that is also hard to do in SQL in an efficient way, I currently do not know how/if we can implement this feature request in the TaskQuery API. If the use case is only process testing with Camunda BPM Assert, have a look at CAM-12178. In the scope of assert, we may be able to implement a solution, because here we an inefficient solution is probably fine.

Lastly, as our near future is planned out, I'm not scheduling the ticket. You can bring this to the stakeholder meeting for prioritization via Andre or Ragnar if you like.

We are closing this ticket as part of our backlog grooming. Reasons:

• It is very unlikely that we will implement this