Timeout configuration

[gsanchezgavier]

Context:
Hi, our application is currently initialising a single client with default timeouts (connection 30s, write/read 295s). This client is used for reflectors as well as other requests inside our application.
Some times we see API responses, like the call to pinned_kind timing out after 295s and we want to reduce that (fail faster).

Issue:
If we reduce the client read/write timeout , our reflectors start timing out.

kube_runtime::watcher: watcher error: ReadEvents(Custom { kind: Other, error: Service(hyper::Error(Body, Kind(TimedOut))) })

Question:
So we are thinking to change our approach and create a client that will be used only for reflectors (with default timeout of 295s) and create another client for any other non-watch operation with a smaller timeout.
Does it make sense? is there any other better way to approach this issue?

[clux]

i guess this approach makes sense on paper. doesn't sound too hard to do on the user side, and i've never heard of anyone else needing this.

that said, i am also very curious as to why oneshot discovery would time out! It's generally a single query, not normally one that interacts with timeout rules, so very weird that you have that dangling, non-watch query, waiting for almost 5 minutes. Maybe it would make sense if you were doing discovery on some kind of extension apiserver, and the extension isn't actually doing the work? I dunno. Any particular CRs you are running discovery on?

[gsanchezgavier]

Thanks for answering!

i am also very curious as to why oneshot discovery would time out!

We have seen it happening on a minikube cluster dev/test environment , usually hammered by integration tests, is hard to reproduce it, so we haven't found out any root cause.

Any particular CRs you are running discovery on?

Yes a Flux HelmRelease

2025-06-04T10:35:10.9443967Z 2025-06-04T10:35:10 DEBUG HTTP{http.method: GET, http.url: https://192.168.49.2:8443/apis/helm.toolkit.fluxcd.io/v2, otel.name: "HTTP", otel.kind: "client"}: kube_client::client::builder: requesting
2025-06-04T10:40:00.9470359Z 2025-06-04T10:40:00 DEBUG HTTP{http.method: GET, http.url: https://192.168.49.2:8443/apis/helm.toolkit.fluxcd.io/v2, otel.name: "HTTP", otel.kind: "client" http.status_code: 200}: kube_client::client::builder: close, time.busy: 3.47ms, time.idle: 290s

The CRD should exist in the cluster at this point, previous calls looks for another CRD (HelmRepository) with success.