-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[receiver/k8sobjects] Add logic to properly handle 410 responses #26098
[receiver/k8sobjects] Add logic to properly handle 410 responses #26098
Conversation
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
@dmitryax @evan-bradley please take another look. |
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.
LGTM
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.
Looks good overall. One additional thing I noticed is that the RBAC section of the docs for this receiver should be updated to mention that list
permissions should now be granted even if a resource_version
is specified.
Description:
Updates the receiver to properly handle 410 response code. The expectations for what clients should do when a 410 is received can be found here: https://kubernetes.io/docs/reference/using-api/api-concepts/#410-gone-responses.
I originally implemented this feature directly in
startWatch
, rebuilding the watcher and res channel within the for loop, but I grew concerned about making sure everything stopped correctly. I took a look at the retry watcher's implementation and reused its concepts for this implementation. If it is overcomplicated we can go back to my original idea.Link to tracking Issue:
Closes #24903
Testing:
Tested locally. Unit tests proved to be extremely challenging since I couldn't figure out how to get the mock to produce a 410. We really need e2e tests (#18395).