FEEL Expression evaluates to null, instead of ignoring missing element in JSON

[jothikiruthika]

Describe the bug
A FEEL Expression to count the number of times a specific key, value pair occurs in a JSON input, returns null, when the filtered key is missing in the input.

To Reproduce

can be reproduced in the playground - https://camunda.github.io/feel-scala/docs/playground/

Input JSON :

{
    "item": "test",
    "id": "4444fa36-642f-458c-bac2-45678941bed",
    "values": [
        {"one":"some one","two":"some two"},
        {"one":"some one","two":"some two"},
        {"one":"some one","two":"some two"},
        {"one":"some one"}
    ]
}

FEEL Expression -

{"oneCount" :  count(values[one="some one"]),  "twoCount" : count(values[two = "some two"])}

Here, with the above JSON, the value of OneCount is 4, but the value of twoCount is NULL

Expected behavior

Ideally, the value of twoCount should be 3, since the property "two" appears 3 times in the input.

Environment

• FEEL engine version: 1.15
• Affects:
  • Camunda Automation Platform 8.1

[saig0]

The underlying issue is that the expression values[two = "some two"] is not evaluated successfully because the key "two" doesn't exist in the last value. Since the expression is wrapped into the count() function, it returns null instead.

This case is not mentioned explicitly in the DMN specification. But it mentions that the access of the context entries by their key is only a shortcut. So, the expression could be also written as values[item.two = "some two"].

The expression item.two is not evaluated successfully if the context doesn't contain a key "two". So, it is consistent that the filter expression is also not evaluated successfully.

Workaround

{
  "oneCount" : count(values[one="some one"]), 
  "twoCount" : count(values[get value(item, "two") = "some two"])
}

It used the get value() function that returns either the value of the given key or null.

[saig0]

After a discussion, we agreed that it could make sense to handle non-existing variables or context entries gracefully in comparisons and filter expressions.

As a result, the filter expression would ignore the missing property and return only the matching entries.

[saig0]

We have a confirmation that the filter should ignore the element without the property and should return the other elements that match the filter. See here: #582 (comment).

[saig0]

Closing this issue in favor of #582. Both issues are about the same problem.