Requests hang if watch=true and there are no objects matching query

[corruptmem]

To reproduce:

var config = KubernetesClientConfiguration.BuildDefaultConfig();
var client = new Kubernetes(config);

Console.WriteLine("FOO");
var podStream = await client.ListNamespacedPodWithHttpMessagesAsync(
    "default",
    labelSelector: "app=1234", // <----- TRY COMMENTING ME OUT
    watch: true);

Console.WriteLine("BAR");

podStream.Watch<V1Pod>(
    (evt, pod) => Console.WriteLine($"{evt}: {pod?.Metadata?.Name}"),
    Console.WriteLine,
    () => Environment.Exit(0));

Console.WriteLine("WATCHING");
Console.ReadKey();

Expected: Output FOO, BAR, WATCHING then as any new pods get created, for the event to be printed

Actual: Outputs FOO then the program hangs until at least one pod gets created

If you comment out the labelSelector, the problem goes away - presumably unless you had a Kubernetes cluster with no pods in the default namespace.

---

Although it is possible to workaround this by treating the ListNamespacedPodWithHttpMessagesAsync (and similar) calls as taking an indefinite time to return under normal circumstances, it's not what I expected to happen when using the watcher.

The root cause of the issue appears to be the LineSeparatedHttpContent class used in the WatcherDelegatingHandler. It appears that inside SerializeToStreamAsync it "peeks" the first line which then calls ReadLineAsync and blocks until there's something to read.

[tg123]

I think it is by design.
call with watch=true would return a stream, something like you are downloading a big file.
the call will hang until everything was read if there is no WatcherDelegatingHandler and it is impossible due to watched stream never end until timeout.

Maybe the better solution is to wrap List and Watch into one sugared watch

What do you think?

[corruptmem]

@tg123 This is essentially what I am now doing, but it makes it all more difficult than it needs to be. Essentially having to translate the async-based List call into working the same way as the callback-based Watch call.

However I think it is possible to implement the List call so it returns immediately if watch is true. I implemented it as a test by having the LineSeparatedHttpContent.SerializeToStreamAsync method not bother peeking the stream, which makes the HttpContent stream (as returned by HttpContent.ReadAsStreamAsync) empty, rather than the first line of the watch result.

It works for my purposes, but I'm not sure what doing that might break in the rest of the client.

[brendandburns]

List and Watch should be separate calls...

[tg123]

call WatchNamespacedPodAsync?

[corruptmem]

@tg123 WatchNamespacedPodAsync has the description: "deprecated: use the 'watch' parameter with a list operation instead, filtered to a single item with the 'fieldSelector' parameter.". I believe the Watch* APIs use the /watch API that was deprecated by kubernetes/kubernetes#65147

[qmfrederik]

@corruptmem Yes, that seems to be correct. We should be able to just update the Watch* APIs to use the ?watch=true parameter, though.

It'd involve updating the KubernetesWatchGenerator project and then re-running the generator.

Would you want to pop a PR for that?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.