Safe Evaluation Mode

[salvalcantara]

Problem Statement

Given potentially incomplete data, I want CEL expressions to evaluate negatively instead of failing.

Examples

For the following JSON payload:

{
  "a": [ 
    {"b": 1, "c": [1, 2, 3], "d": "foo"},
    {"b": 2, "d": "bar"},
    {"c": [0]}
  ]
}

I want these expressions to evaluate to false, for example:

size(aaa) > 0
aaa.exists(x, x.b == 1)
a.exists(x, x.b == 3)

As of now, all will fail due to missing fields. An obvious solution is to make the expressions safe beforehand like this:

has(aaa) && size(aaa) > 0
has(aaa) && aaa.exists(x, has(x.b) && x.b == 1)
has(a) && a.exists(x, has(x.b) && x.b == 3)

But that's precisely what I want to avoid.

Proposed Solution: Safe Evaluation Mode

The main idea would be to replace unresolvable attributes with null.

For a.b == 1 that would give us null == 1 which would evaluate to false as desired.

The problem is when you have something more like this a.b > 1 because that would be transformed into null > 1 and then evaluation would fail with a no such overload error due to the null type not supporting the > operator. The same might happen for other operators/functions. To account for this, the interpreter could consider an evaluation type of middleware which simply inspects if there are any (non-)errors like those due to missing fields and if that's the case simply return false.

I originally posted the idea here:

• Safe Evaluation Mode projectnessie/cel-java#630

It also related to optionals as discussed here:

• https://github.com/google/cel-spec/wiki/proposal-246

[salvalcantara]

Instead of replacing unresolvable attributes with null, one could use a singleton Undefined (or Missing) data type along the lines of Optional Chaining in JavaScript. By overloading all the operators for this data type to simply propagate the undefinedness (missingness), the whole expression would continue making sense, bettering the design from a type perspective.

[salvalcantara]

I guess Optionals (proposal 246) are enough for handling the described problem. If so please feel free to close the discussion.

[TristonianJones]

Hi @salvalcantara,

It may not seem like it, but errors are the only safe way to handle this scenario for dynamic types. It's never clear whether the undefined field referenced is intentionally absent. Instead of coalescing to false which can be negated and lead to logical errors, we use error which cannot be negated.

Whether an error is fail open or fail close is also an application decision that's beyond the purview of what CEL understands.

But, in general, yes, the optionals are a better way to state intentionally undefined fields in a dynamic object

-Tristan

[salvalcantara]

Makes sense. Thanks for the reply @TristonianJones!