The ability to automatically stop on context cancellation was new functionality
that adds complexity and wasn't really used in Kubernetes. If someone wants
this, they can add it outside of the function.
A *WithLogger variant avoids the complexity and is consistent with
NewStreamWatcherWithLogger over in apimachinery.
Kubernetes-commit: 1a8d8c9b4a33daf9330434e1ad544ef3571722a3
The Lister and Watcher interfaces only supported methods without context, but
were typically implemented with client-go API calls which need a context. New
interfaces get added using the same approach as in
https://github.com/kubernetes/kubernetes/pull/129109.
Kubernetes-commit: 6688adae142e37114d9dfa8d94cd1d8a91fbcc13
- Switch to using the ProxyWatcher to validate the dance between
closing the stop channel and closing the result channel.
- Use the new clientfeaturestesting.SetFeatureDuringTest to test with
the WatchListClient enabled and disabled. These should result in
almost the exact same output events from the informer
(list ordering not garenteed), but with different input events
recieved from the apiserver.
Kubernetes-commit: 28e3a728e5e6fe651d7a17839d33ce42204c0b4e
There was some weird queuing going on. The queue was implement by
spawning goroutines that would block on the "ticketer" until it was
their turn to write to the output channel. If N events where in the
watch when the consumer of the watch stopped reading events, N
goroutines would leak. In unit tests of the certificate manager, this
was causing ~10k goroutines to leak.
Fix it with a buffering event processor that uses only one routine and
cancels correctly.
Kubernetes-commit: cafc640bfa0f7362b178b1b896085962d018afe3
