Repository navigation
Watch keepalive not working anymore with 1.0.0 #2127
Description
Activity
My guess is that the fix from the v0.x branch just never made it to the v1.x branch. Does applying the fix from #630 fix the issue for you locally?
If it does fix the issue, I also wonder if we even need the
net-keepalivedependency from #630. It looks like they have documented that newer versions of Node used by the v1.x branch may not need the dependency - hertzg/node-net-keepalive#318.node-fetchdoesn't support keepalive out of the box, you need to use an Agent, see node-fetch/node-fetch#423Actually, in 0.22.2,
net-keepaliveis already removed in favor ofsocket.setKeepAlive(): https://github.com/kubernetes-client/javascript/blob/0.22.2/src/watch.ts#L120 (PR: #635)So I guess, we need to access the socket and apply the same options, I will try to do a PR.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
- After 90d of inactivity,
Describe the bug
With the version 1.0.0, when a
watchrequest is made and the connection drop, no more events are reported, but there is also no error that indicate that the connection was dropped. (I waited 10 minutes to be sure)With version 0.22.2, under ~33s, I got the error
read ETIMEDOUT, allowing me to retry the connection and restart the watch request.This issue was already raised on #559 and fixed with PR #630. This PR add a config to configure keepalive packets in
watch.ts, but I don't see this config on the version 1.0.0.Client Version
1.0.0(but working on 0.22.2)Server Version
1.30.3To Reproduce
In my case, I start the
watch-example.tsand then cut the VPN connection to my cluster. As it's related to network perturbation, it's not easy to suggest an easy reproducible way to do it. I guess you can also use your firewall to drop packets in the middle of a watch request.Expected behavior
I expect an error to be thrown when the Kubernetes api becomes unavailable while a watch request is running like it was the case for previous versions.
** Example Code**
I used the
watch-example.tsEnvironment (please complete the following information):