Alexander Kaplan

@akning-ms @raosuhas I fixed all the issues I could. The checks that fail - I don't really understand them, and not sure if they are internal tooling issues or relevant...

@rossanthony my watches were correctly disconnecting at timeout (if no timeout is specified it fairly randomly disconnects around 5 minutes, which I assume is the default set on Kube API...

@rossanthony It never times out, it hangs forever. The way I noticed is because we have a watchdog running in a background loop that logs seconds elapsed since our most...

Here's what I'm seeing (1.0.0): - with 300 pods running (each constantly watching with a 240 second timeout on the watch: one watch ends or fails, the next one immediately...

@rossanthony not yet, I need to wait for days to establish base lines. I will soon and report back. Keep in mind though that I did see both pods get...

@rossanthony so I was able to reproduce and here's what happens. The `watch()` call does not hang, it immediately returns a `Promise` as designed. The problem is - if I...

In 1.2.0 this does not seem to reproduce; I'm getting either normal watch callback invocation once the timeout is reached (no error, so I guess it still doesn't know something...

With 1.2.0 I do see a permanently hanging request though - _listClusterCustomObject_ just hung on me permanently, the call was: ``` crsResult = await k8sApi.listClusterCustomObject({ group: K8sWatcher.crdApiGroup, version: K8sWatcher.crdApiVersion, plural:...

@brendandburns Yes, it's just a normal list. It hung, no data back after 5 hours, the function never returned. I'm on a regular AKS cluster, no funny business. I wasn't...

/AzurePipelines run