You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Directly comparing a pair of Timestamps or Durations using either == or != will result in an expression with an estimated cost of math.MaxUInt. Other operators (>, <=, etc.) are not affected, and will return a low constant cost as expected. As far as I can tell, this is because operators besides ==/!= have type-specific overloads and thus fall through to the default case of coster.functionCost.
But this is not so for ==/!=, which are handled by the same case that handles all equality/inequality checks. coster.sizeEstimate, called a bit further down, doesn't know how to handle Timestamps/Durations and returns math.MaxUInt. This is a similar issue to what #571 fixes, though it's a bit different here - I think it should be fixable just by adding an extra overload on ==/!= for both Timestamps and Durations.
This should be resolved before a new release is cut to pick up #571 - I can take care of this issue as well (I'd self-assign but it seems I don't have the right permissions unfortunately).
To Reproduce
Check which components this affects:
parser
checker
interpreter
Sample expression and input that reproduces the issue:
timestamp1 == timestamp2
duration1 != duration2
Test setup (add the following tests to TestCost in cost_test.go):
Describe the bug
Directly comparing a pair of Timestamps or Durations using either
==
or!=
will result in an expression with an estimated cost of math.MaxUInt. Other operators (>
,<=
, etc.) are not affected, and will return a low constant cost as expected. As far as I can tell, this is because operators besides==
/!=
have type-specific overloads and thus fall through to the default case ofcoster.functionCost
.But this is not so for
==
/!=
, which are handled by the same case that handles all equality/inequality checks.coster.sizeEstimate
, called a bit further down, doesn't know how to handle Timestamps/Durations and returnsmath.MaxUInt
. This is a similar issue to what #571 fixes, though it's a bit different here - I think it should be fixable just by adding an extra overload on==
/!=
for both Timestamps and Durations.This should be resolved before a new release is cut to pick up #571 - I can take care of this issue as well (I'd self-assign but it seems I don't have the right permissions unfortunately).
To Reproduce
Check which components this affects:
Sample expression and input that reproduces the issue:
Test setup (add the following tests to
TestCost
incost_test.go
):Expected behavior
The tests should pass. However, on my system I get the following output:
Additional context
cel-go revision:
25bb4c6da1759f0104ce8ee935431d32b71977b6
The text was updated successfully, but these errors were encountered: