Unable to use the same input/output element in multi-instance

[korthout]

Describe the bug
Although undocumented, zeebe currently does not support referring to the same variable in the input element and the output element of a multi-instance element.

This is likely due to the nil initialisation of the output element variable (in the case that the output element expression is either a variable name or the name of a property of a variable).

To Reproduce

• deploy https://gist.github.com/korthout/2038aae67d9692d5d7776e17a50d5ea9
• create instance: zbctl create instance Process_0ci0xjm --variables='{"Book":{"Title":"My Book","pages":[{"PageNumber":1,"IsRead":false},{"PageNumber":2,"IsRead":false}]}}'
• an incident is raised: "failed to evaluate expression '{page:{PageNumber:page.PageNumber,isRead:true}}': expected Context or List of Contextes but found 'ValNull'"

Expected behavior
In the above case, I expect the variable page:

• to be initialised to an element of the input collection, at the start of the multi-instance body;
• to be changed by the service task;
• to be collected into the output collection variable (i.e. pages) at the end of the multi-instance body.

Environment:

• OS: macOS 10.15.5
• Zeebe Version: 0.24.0-alpha2 (probably also 0.23.2)
• Configuration: hazelcast-exporter 0.9.0 and simple monitor 0.19.0

[korthout]

Workaround is available: use different variable names for input and output element.

[korthout]

Closed in favor of duplicate but up-to-date #7330

[korthout]

Reopened, because it's not the same case #7330. That issue was related to the output collection expression hiding the input collection variable.

In this issue, the output element is NIL initialized after the input element is created. If they have the same name, the just created input element variable is overwritten (UPDATED) to NIL. Either it shouldn't be updated if it refers to the same element, or the NIL initialization should happen before the input element variable is created.

[korthout]

Sev should be mid, it has a noticeable impact but a workaround is available.
I was also able to reproduce this on 8.0.4, so the bug still exists