"Complex" unary tests with "true" expressions ignore input value

[par-shd]

Describe the bug
While using the FEEL engine, I encountered situations where the unary tests keep returning "true", while they shouldn't. Let's consider the following 3 cases as valid responses:

1. Expression: true
   Input: false
   // Result: false
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=unary-tests&expression=dHJ1ZQ%3D%3D&context=e30%3D&input-value=ZmFsc2U%3D

2. Expression: true
   Input: null
   // Result: false
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=unary-tests&expression=dHJ1ZQ%3D%3D&context=e30%3D&input-value=bnVsbA%3D%3D

3. Expression: true
   Input: "hello"
   // Result: null with a warning [NOT_COMPARABLE]
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=unary-tests&expression=dHJ1ZQ%3D%3D&context=e30%3D&input-value=ImhlbGxvIg%3D%3D

To Reproduce
Now if I make the expression a bit "complex", I'll get unexpected results. Consider the same tests, but this time with the expression: 3 > 1

1. Expression: 3 > 1
   Input: false
   // Result: true
   // Expected: false
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=unary-tests&expression=MyA%2BIDE%3D&context=e30%3D&input-value=ZmFsc2U%3D

2. Expression: 3 > 1
   Input: null
   // Result: true
   // Expected: false
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=unary-tests&expression=MyA%2BIDE%3D&context=e30%3D&input-value=bnVsbA%3D%3D

3. Expression: 3 > 1
   Input: "hello"
   // Result: true
   // Expected: null with a warning [NOT_COMPARABLE]
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=unary-tests&expression=MyA%2BIDE%3D&context=e30%3D&input-value=ImhlbGxvIg%3D%3D

You can test the same cases, but with different expressions. The following expressions also lead to the same problem (and probably more cases):

• all([true])
• any([true])
• contains("foobar", "foo")

Expected behavior
The expression must be compared with the input. It shouldn't be always "true"

Environment

• FEEL engine version: [1.18.1]

[saig0]

@par-shd thank you for raising it.

This is an interesting question. I understand the behavior is confusing because the unary-tests expressions true and 3 > 1 result in different outcomes.

However, the specification is also ambiguous in this case: (ref)

I would argue that the unary-tests expression 3 > 1 should return true since the expression evaluates to true (first case).

---

@par-shd do you have a concrete use case?

[par-shd]

@saig0 Thanks for the quick response. I don't think the situation meets the first case, more specifically the "when the input is applied to the unary operators" part
In the given examples, we have the "equal to" operator, ref

And if the operator is applied, we'll get 3 expressions that correspond to the 3 cases:

1. false = (3 > 1)
   // Result: false
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=expression&expression=ZmFsc2UgPSAoMyA%2BIDEp&context=e30%3D

2. null = (3 > 1)
   // Result: false
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=expression&expression=bnVsbCA9ICgzID4gMSk%3D&context=e30%3D

3. "hello" = (3 > 1)
   // Result: null with a warning [NOT_COMPARABLE]
   https://camunda.github.io/feel-scala/docs/playground/?expression-type=expression&expression=ImhlbGxvIiA9ICgzID4gMSk%3D&context=e30%3D

Which are the same as the expected results as described within the original issue

[saig0]

"when the input is applied to the unary operators" part

Yes, but this is only true if the equals unary operator is applied. The FEEL grammar is ambiguous because a unary-tests expression can contain unary operators or regular expressions. So, 3 > 1 could mean ? = (3 > 1) (equals unary operator) or true = (3 > 1) (evaluates to true).

Here is the definition from the DMN specification: