nzw921rx commented on PR #12460: URL: https://github.com/apache/seatunnel/pull/12460#issuecomment-6173379914
> ## Strict review — `0fe84659d5eb710ee1c99ef88a260e103a9ac54f` > ### Blocking > * **[P1] Make persistent watch connection failures exhaust the application failure budget.** `InformerPodWatch` only starts and evaluates its 90-second budget when `handleWatchFailure` is called ([InformerPodWatch.java#L150-L174](https://github.com/apache/seatunnel/blob/0fe84659d5eb710ee1c99ef88a260e103a9ac54f/seatunnel-resource-managers/kubernetes/src/main/java/org/apache/seatunnel/resource/kubernetes/kubeclient/InformerPodWatch.java#L150-L174)). The bundled Kubernetes Java client 19.0.1 handles a `ConnectException` while opening or reopening a watch internally: it sleeps for one second and retries in its watch loop without calling the informer exception handler. Consequently, an API-server connection refusal can continue forever without reaching this method or completing `onWatchError`. The application is then blind to Kubernetes worker-pod loss during the outage; the normal Hazelcast member-removal path only removes the worker profile and does not fail the application ([Abstr actResourceManager.java#L177-L184](https://github.com/apache/seatunnel/blob/0fe84659d5eb710ee1c99ef88a260e103a9ac54f/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/resourcemanager/AbstractResourceManager.java#L177-L184)). This is reachable in a normal production control-plane outage and can leave a fixed-size application running with a missing worker rather than failing deterministically. > Please use a watch wrapper that reports every failed reconnect to the application-level failure policy, or add an independent deadline that is reset only after a successful list/watch event and calls `onWatchError` on expiry. Add a deterministic test that repeatedly injects `ConnectException`, exceeds the 90-second budget, and proves that the application failure future completes. > > ### Scope and verification > * I reviewed the full current PR diff and affected application, Kubernetes-resource, lifecycle, cleanup, configuration, packaging, documentation, and E2E call paths. The prior Windows/RBAC/inline-secret issues are addressed at this head. > * The issue above blocks merge because it invalidates the newly documented bounded failure semantics for a real control-plane failure path. > * No additional standalone-Zeta compatibility or checkpoint-format break was identified in static review. > * I did not run a local Maven build or Kubernetes suite. At review time, GitHub only showed the labeler and notification checks queued for this head. > > **Recommendation: do not merge until the watch-failure budget covers reconnect `ConnectException` failures and has regression coverage.** fixed,thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
