Script task FEEL `expression` not recognized as typed available FEEL context

[nikku]

Describe the bug

If I use a bpmn:ScriptTask with a FEEL expression the actual expression is not added to editor intelligence, only the fact that an output variable exists:

Steps to reproduce

1. Create a script task with implementation FEEL expression
2. Assign a value, and resultVariable
3. Use the resultVariable elsewhere on the diagram
4. See that value information is not provided, though it is available (through the FEEL expression)

Expected behavior

• Value (structure) is parsed from the FEEL expression on a best effort basis, and provided, as it is the case for other expressions:

  

Environment

• OS: Linux
• Camunda Modeler Version: v5.28.0
• Execution Platform: Camunda 8
• Installed plug-ins: None

Additional context

No response

[nikku]

CC @mschoe (we discussed and detected this issue).

[marstamm]

@marstamm to have a time-boxed look into this, either fix or give implementation hints to be picked up by the team

[marstamm]

Context

This turns out to be a deeper problem than anticipated. While it is quite simple to parse result from a script task, I uncovered some deeper problems with our Variable resolving.

The "simple but wrong" solution can be found on this branch https://github.com/bpmn-io/variable-resolver/tree/parse-zeebe-script.

The Edge cases are:

• Input or Output mappings bind to the same variable name as the script
• There are Output mappings <-- also a problem without adding Feel context

Problems

Assume the following Script task:

   inputMapping:    foo = 1
   Feel Script:     foo = 2
   outputMapping:   foo = 3

The smallest scale for scopes we currently support is Task level. In this case, we would only have 2 Variable assignments. For the local variable, it is unclear if it should evaluate the input mapping or the feel script, an which result to use in the output mapping.

Additionally, I found that our current Variable Resolver does not properly scope the result variables. In https://github.com/bpmn-io/extract-process-variables/blob/main/src/zeebe/util/ProcessVariablesUtil.js#L54-L58 , the scope is defined as the parent which has an input mapping with the same name. This is correct on a process level, but not on task level. Any Variable that is in Task scope (such as in the example) should not be propagated to the process. So this diagram: Only mappedResult should be suggested. However, scriptResult is also suggested

[abdul99ahad]

Here’s my understanding of the two main issues:

• FEEL Expression Parsing for Script Tasks
• Variable Scoping
  • Handling local variables within the same task.
  • Managing variables that other tasks can access.

[nikku]

@abdul99ahad is the solution already integrated into the modeler? If not, please move this issue to fixed upstream, and work towards the integration of the fixed upstream library.