Maximum call stack size exceeded in variable resolver

[barmac]

Describe the bug

Sentry still reports RangeError despite bpmn-io/variable-resolver#23

Sentry report

Steps to reproduce

I can't tell.

Expected behavior

No errors.

Environment

• OS: [e.g. MacOS 10.2, Windows 10]
• Camunda Modeler Version: 5.20.0
• Execution Platform: [e.g. Camunda 7, Camunda 8]
• Installed plug-ins: [...]

Additional context

No response

[CatalinaMoisuc]

We have ~3k events for ~4 users. We should try to root cause the issue before deciding if this should be fixed.

[CatalinaMoisuc]

As per @barmac's initial assessment, this issue might be crashing the modeler:

unhandled error in event listener RangeError: Maximum call stack size exceeded

[nikku]

We have some options:

• Add additional guardrails to ensure that errors are more comprehensive
• Add recursion counter and bail out (with proper context) on, i.e. > 100 depth
• Wait for customer to report a bug with clear steps to reproduce

Leaving to @marstamm to assess further once he is back.

[marstamm]

This is indeed another problem than what we fixed previously. What is happening here is that the user has a very big context, like 10k+ entries. We use .push(...arr), which creates a stack for every entry in the array it is adding.

We can prevent this from happening by using different methods of concatenation. What would be interesting to see is if the user actually creates such contexts or if the big amount of entries is a bug.

[marstamm]

This one was a doozy:

Background
Let's take a look at the following output mapping:

When we resolve output mappings, we create a new interim variable that will be merged at a later point. This ensures that we can correctly handle multiple output mappings with different types and can do the merging in a central space. The interim variables copy all the information from the original variable, so the context information can be displayed in variable suggestions. This is mainly used for nested variables/compositions.

So for the example above, we will have as interim Variables that will be merged:

{
  // Created from Moddle schema
  name: 'foo',
  origin: ['bar'],
  provider: [defaultProvider]
},
{
  // Created from FEEL parsing
  name: 'foo',
  type: 'Number',
  value: 15,

  // copied from original one
  origin: ['bar'], 
  provider: [defaultProvider]
},
{
  // Created from FEEL parsing
  name: 'foo',
  type: 'String',
  value: 'bar,

   // copied from original one
  origin: ['bar'], 
  provider: [defaultProvider]
},

Root Cause
Unfortunately, when merging, we missed to adjust the duplicate checking for also working correctly with providers when we decided to also keep track of variable providers. Therefore, duplicated providers were added to the list.

Because we only copied the reference of the provider array and not the array itself, the size of the array grew exponentially with the number of output mappings.

Together with the spread operator implementation described in #4139 (comment), this leads to a stack size exceeded when you have ~20 mappings for the same variable name.

[nikku]

Waiting integration, fixed upstream via camunda/camunda-bpmn-js#352.

[barmac]

Related: bpmn-io/bpmn-js-element-templates#78