fix(cache): watch errors must call done handler #781
Conversation
The type of `watchObject` was incorrect and has been updated to match the actual request body. Using this info it was clear that 'ERROR' events were not being handled correctly. When the watch receives an error it is not always an http status code, because the status code can only be sent when the stream is starting. This means that `410` resourceVersion out of date errors could only be handled if they were detected before the watch stream started leaving watches running on channels that would never receive more events and not notifying `ListWatch` consumers of the error.
|
/lgtm Thanks for the PR! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bbatha, brendandburns The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
hello, I wonder when this fix will be published to next release?some background of my case: my concluded timeline: you could reproduce by setting a expired initial value of resourceVersion at ListWatch for see my case |
The type of
watchObjectwas incorrect and has been updated to matchthe actual request body.
Using this info it was clear that 'ERROR' events were not being handled
correctly. When the watch receives an error it is not always an http
status code, because the status code can only be sent when the stream is
starting. This means that
410resourceVersion out of date errors couldonly be handled if they were detected before the watch stream started
leaving watches running on channels that would never receive more events
and not notifying
ListWatchconsumers of the error.