google
Fix nested CallExpr cost estimation
This PR fixes instances where cost estimation is used on expressions where a CallExpr is nested inside of another CallExpr and math.MaxUint64 is incorrectly returned. The test case included with this PR shows an example of where this can happen; == is treated as a function call/CallExpr, and will call sizeEstimate on its left and right-hand expressions. sizeEstimate will then try to call AstNode.ComputedSize before trying EstimateSize and finally returning math.MaxUint64 for an upper limit.
That constant will get returned for operator-based CallExprs inside CallExprs whenever the inner one lacks an EstimateSize, such as with list.size(). Instead, this PR checks for CallExpr inside SizeEstimate and returns a min/max cost of 1.
The original issue was first reported in https://github.com/kubernetes/kubernetes/issues/111769.
Please add a link in the description to k8s issue where this was discovered.
@TristonianJones I'd like to backport the fix to Kubernetes 1.24 and 1.23 if possible.
Once this is ready, would it be possible to backport to cel-go v0.10 and v0.9? These are the CEL versions those Kubernetes releases depend on (https://github.com/kubernetes/kubernetes/blob/release-1.24/go.mod#L267, https://github.com/kubernetes/kubernetes/blob/release-1.23/go.mod#L272)
@jpbetz I'll cherry pick the squashed commit back into the previous releases with minor version bumps, e.g. v0.11.5, v0.10.2, v0.9.1. Sound good?
Joe Betz I'll cherry pick the squashed commit back into the previous releases with minor version bumps, e.g. v0.11.5, v0.10.2, v0.9.1. Sound good?
Thank you so much. I realize this is tedious.