-
Notifications
You must be signed in to change notification settings - Fork 78
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: treat rate limiter deadline as context deadline #635
base: master
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: levenleven The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Welcome @levenleven! |
Hi @levenleven. Thanks for your PR. I'm waiting for a kubernetes-sigs 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. Instructions 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/test-infra repository. |
|
||
func errWouldExceedContextDeadline(err error) bool { | ||
if e := errors.Unwrap(err); e != nil { | ||
return e.Error() == "rate: Wait(n=1) would exceed context deadline" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very fragile. There should be at least a test for this. Ideally the wait package should have a type for this.
Also, this doesn't feel like the right spot for this logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, ideally rate
package would return a typed error here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a test.
Also, this doesn't feel like the right spot for this logic.
Do you have a suggestion what would be a better place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe somewhere up the call stack. I'm not a maintainer of this project, just a user, so this may be fine with maintainers.
a8d5ec1
to
6ebac4a
Compare
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
FWIW, we mostly avoid this problem by disabling client-side throttling and depending on server-side throttling to handle slowing down requests. If you do the same, you shouldn't ever see any Unfortunately, that error doesn't have a type, which makes it fragile to catch. And unwrapping only once is also fragile. You would need to either fully unwrap recursively or check for a partial match in the full error message to catch all the edge cases. That said, what is the behavior you're looking for? Won't it still be status unknown if the context is cancelled? |
/ok-to-test |
@karlkfi Thanks for looking into this!
No, the poller would keep the previous known status. With current behavior the error is swallowed and the status is overridden with
If this has a chance to be accepted I can do that 🙂 |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
We often bump into race condition where resource status won't be read because context is reaching the deadline. This results in
Unknown
status being returned.This PRs treats this edge case the same way as
context.Canceled
andcontext.DeadlineExceeded
are treated.