Does the Kubernetes API server end a watch stream promptly when the client cancels its context?

client-go's watch interfaces take a context.Context, and cancelling it is the documented way to stop a watch. On the wire, though, a watch is one-way server push: once the stream is established there is no in-band cancellation frame, so the server has to infer that the client is gone.

How quickly it infers that appears to depend on the transport. Over HTTP/2 the client can reset the stream; over HTTP/1.1 the server may only notice when it writes the next event, or when the timeout behind --min-request-timeout fires. Watch cache, aggregated API servers, and proxies in the path could each change the picture.

Assume a recent stable cluster (say 1.34–1.37) with matching client-go and default HTTP/2 negotiation. The goal is to decide whether application code can rely on prompt server-side teardown after context cancellation, or whether operators should treat lingering watch handlers as normal and size timeouts accordingly.

1. Does an HTTP/2 RST_STREAM from a cancelled client-go watch terminate the API server's watch handler immediately, or only at the next event?
2. Do HTTP/1.1 and HTTP/2 clients differ here, and is the behavior consistent across the 1.34–1.37 releases?
3. What is a reliable way to measure teardown latency in a test cluster without attributing proxy or load-balancer behavior to the API server?