Retry on request-interrupted watch failures

[nkottary]

Summary

• Long-lived Pod watches can be interrupted by transient connection resets (idle LB/proxy timeouts, apiserver restarts, network blips), which OpenAPI.jl surfaces as InvocationException("request was interrupted").
• k8s_retry_cond previously only retried ApiException with specific retryable status codes, so this case propagated straight to callers as an unrecoverable error.
• This treats OpenAPI.Clients.is_request_interrupted(e) as retryable too, matching the existing is_longpoll_timeout handling used elsewhere for watch reconnects.
• Bumped patch version (0.7.10 -> 0.7.11).

Context

Found while investigating a JobLoops production error: K8sReflector's pod-monitoring watch loop was hitting this exact InvocationException and falling through to a full restart (re-list + re-watch) instead of a quiet reconnect. A companion fix on the K8sReflector side (JuliaTeam repo) now also treats is_request_interrupted leniently; this Kuber.jl change closes the gap at the lower retry layer too.

Test plan

• Pkg.test() in Kuber.jl
• Manually verify k8s_retry_cond returns (s, true) for an OpenAPI.Clients.InvocationException("request was interrupted")

🤖 Generated with Claude Code

[tanmaykm]

One mechanism provided to the consumer of watch events to signal a termination of the watch loop is to close the watch stream/channel. Does that also throw an is_request_interrupted exception?

If so, then would this change prevent the loop from terminating as the event consumer would have wanted?

[nkottary]

Good catch, thanks. Confirmed: in the :downloads backend, closing the watch channel is exactly the documented mechanism for a consumer to stop a watch, and it goes through the same interrupt path that leaves resp === nothing in exec() — so it does throw the same InvocationException("request was interrupted") as a genuine dropped connection.

Pushed a follow-up commit that threads the event/output stream through k8s_retry/k8s_retry_cond, so it only treats is_request_interrupted as retryable while that channel is still open. If the channel's already closed, that means the consumer asked to stop, so it's allowed to propagate instead of being retried.