New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix CEL cost handling of zero length replacement strings #120097
Conversation
d725a12
to
60c512b
Compare
/cc @Rajalakshmi-Girish |
/lgtm
|
LGTM label has been added. Git tree hash: 034969ae302920a6d5004b023ad04c8d0cc7e373
|
/retest |
Co-authored-by: Jordan Liggitt <jordan@liggitt.net>
/lgtm |
LGTM label has been added. Git tree hash: e1cec82593af66156924a3036926ff32d41653a8
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dims, jpbetz, liggitt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
once merged, update the cherry-pick PRs (https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+-base%3Amaster+119800) to include this commit |
/hold cancel |
/retest |
/triage accepted |
/retest |
When you see a flaking unit test, please file an issue or add a reference to the existing issue, unit tests should NOT be flaking : ( I don't see one so I filed #120112 |
Changelog suggestion -Fix CEL estimated cost of replace() to handle a zero length replacement string correctly.
-Previously this would cause the estimated cost to be higher than it should be.
+Fixed CEL estimated cost of `replace()` to handle a zero length replacement string correctly.
+Previously this would cause the estimated cost to be higher than it should be. |
Applied. Thanks! |
What type of PR is this?
/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes issues found in ppc64le tests of CEL estimated cost for the
replace()
function: #119800 (comment)The difference in cost was caused by ppc64le calculating this expression differently than amd64:
https://gist.github.com/jpbetz/032b54ce4ef8f5427c4812c023f6c693 shows the exact difference, which is that
uint64(+Inf)
results in 9223372036854775808 for amd64 but 18446744073709551615 for ppc64le (and arm64?).The fix is to avoid the divide the creates the +Inf by handling the cost edge cases for
replace()
. I've verified this fix works on both architectures.Special notes for your reviewer:
Does this PR introduce a user-facing change?
/sig api-machinery