fix(apimachinery): allow 19-digit quantities to support math.MaxInt64#135956
fix(apimachinery): allow 19-digit quantities to support math.MaxInt64#135956Kesavaraja67 wants to merge 1 commit intokubernetes:masterfrom
Conversation
|
|
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Welcome @Kesavaraja67! |
|
Hi @Kesavaraja67. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Kesavaraja67 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
cf52e4b to
2b57ebf
Compare
|
Hi @thockin @derekwaynecarr, I have fixed the CLA and release-note formatting issues. This PR is now ready for review and testing. Could you please take a look and /ok-to-test if this is ready for the CI suite? Thank you! |
|
/sig api-machinery |
|
/sig api-machinery |
|
is this theoretical or a real world scenario? |
|
Hi @dims! To be honest, I found this through code analysis and testing while looking at the parser, so it's 'theoretical' in the sense that I haven't seen a specific bug report for it yet. However, I realized that while math.MaxInt64 is a perfectly valid int64 value, the parser's 18-digit fast-path check effectively blocks it. Since Kubernetes is increasingly used for massive resource quantities (like bytes for very large storage), I figured it was better to fix this logic gap now before it becomes a real-world production issue for someone. |
|
/ok-to-test |
|
@Kesavaraja67: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
What type of PR is this?
/kind bug
What this PR does / why we need it:
This PR fixes a precision bottleneck in the resource quantity parser where 19-digit numbers, such as math.MaxInt64, failed the base-10 fast-path check.
By increasing the digit threshold from 18 to 19 and adding a boundary check using strconv.ParseUint, the parser now correctly supports the full range of int64 values. This prevents parsing failures and avoids unnecessary fallbacks to slower parsing paths for the maximum representable integer in Go (9,223,372,036,854,775,807).
Which issue(s) this PR is related to:
Fixes #135487
Special notes for your reviewer:
This change has been verified using go test and go vet. In particular, math.MaxInt64 now parses successfully within the resource package:
go test -v ./staging/src/k8s.io/apimachinery/pkg/api/resource/Does this PR introduce a user-facing change?