You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The watch capability of the K8s API will return an http status code of 410 and a status object if the resourceVersion supplied to the API is too old. At the moment the receiver handles these situations by logging that they occurred and then stopping the watch for the object in question.
This situation is most likely to occur if a user passes in a resource_version itself, but could occur during normal option as well (although that would be strange).
)
**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:** <Issue number if applicable>
Closes#24903
**Testing:** <Describe what testing was performed and which tests were
added.>
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).
---------
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
Component(s)
No response
Is your feature request related to a problem? Please describe.
The
watch
capability of the K8s API will return an http status code of 410 and a status object if the resourceVersion supplied to the API is too old. At the moment the receiver handles these situations by logging that they occurred and then stopping the watch for the object in question.This situation is most likely to occur if a user passes in a
resource_version
itself, but could occur during normal option as well (although that would be strange).Describe the solution you'd like
Instead of giving up, the receiver could do a new
List
to get a newresourceVersion
. See https://kubernetes.io/docs/reference/using-api/api-concepts/#410-gone-responses for details.The text was updated successfully, but these errors were encountered: