fix: avoid int64 overflow in milli-quantity conversion for large metric values#7534
Conversation
…ic values Values exceeding ~9.2e15 caused int64 overflow when multiplied by 1000 in GetMetricTargetMili() and GenerateMetricInMili(), resulting in metrics being reported as zero. Use resource.MustParse with string formatting instead to handle arbitrarily large float64 values. Signed-off-by: Munem Hashmi <[email protected]>
|
Thank you for your contribution! 🙏 Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected. While you are waiting, make sure to:
Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient. Learn more about our contribution guide. |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
What will happen with this new code when we get a NaN or Inf as result like #7475? |
…version MustParse panics on "NaN" or "+Inf" strings. Add a guard in quantityFromFloat64 that treats NaN/Inf as zero, preventing operator crashes from malformed metric API responses. Signed-off-by: Munem Hashmi <[email protected]>
|
Good catch @rickbrouwer! The previous code would have had undefined behavior for NaN/Inf (silent int64 cast), but with I've pushed a follow-up commit that extracts a |
|
/run-e2e |
|
/run-e2e |
|
/run-e2e github_runner* |
…Type variation The metric type only affects which struct field receives the quantity, not the conversion logic. Use a single metric type to keep the test focused on value conversion. Signed-off-by: Munem Hashmi <[email protected]>
|
/run-e2e internal |
3 participants
Fix int64 overflow in
GetMetricTargetMili()andGenerateMetricInMili()that caused very large metric values (>~9.2×10¹⁵) to be reported as zero.Root Cause
Both functions computed
int64(value * 1000)to create milli-quantities. Whenvalue * 1000exceedsmath.MaxInt64(~9.22×10¹⁸), the conversion silently overflows, producing a negative number that gets reported as zero by the HPA.Fix
Extract a shared
quantityFromFloat64()helper that:resource.MustParsepanics)resource.MustParse(fmt.Sprintf("%.3f", value))instead ofint64(value * 1000)+resource.NewMilliQuantity(), leveragingresource.Quantity's arbitrary precision to avoid int64 overflowChecklist
Fixes #7441