fix(apiserver): return 400 instead of 500 for invalid resourceVersion in API Request#139525
fix(apiserver): return 400 instead of 500 for invalid resourceVersion in API Request#139525Jay-0331 wants to merge 1 commit into
Conversation
Invalid resourceVersion is client input error, not server fault. Map parse failures to StatusBadRequest instead of 500.
|
Welcome @Jay-0331! |
|
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. |
|
Hi @Jay-0331. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. 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: Jay-0331 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 |
What type of PR is this?
/kind bug
What this PR does / why we need it:
The apiserver was returning HTTP 500 (InternalError) when a client supplied an invalid
resourceVersionin list/watch requests. An invalidresourceVersionis a client input error, not a server fault, so it should surface as HTTP 400 (BadRequest). This PR mapsresourceVersionparse failures toStatusBadRequest, allowing clients to distinguish malformed requests from genuine server errors and avoid spurious retries against the apiserver.Which issue(s) this PR is related to:
Fixes #139485
Special notes for your reviewer:
The change is scoped to the error mapping path for
resourceVersionparsing; existing valid-input behavior is unchanged. Please confirm the new status code does not regress any client retry/backoff logic that may have been (incorrectly) keying off the 500 response.Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: