DanielLeens commented on issue #11587: URL: https://github.com/apache/seatunnel/issues/11587#issuecomment-5137560511
Thanks for volunteering to work on this. I rechecked the current `dev` code path before replying. The issue is still valid: `JobMaster#getCurrJobMetrics()` still waits on `GetTaskGroupMetricsOperation` with an unbounded `Future#get()`, and the default `CoordinatorService#getRunningJobMetrics()` path still waits on each `GetMetricsOperation` in the same way. There is a timeout-aware overload for filtered metrics, but the general running/job metrics path is not yet consistently bounded or best-effort. I do not see an open PR for this exact metrics fail-fast scope right now, so the first implementation slice you described looks reasonable: 1. keep the change focused on Worker metrics collection timeouts / partial results; 2. preserve the existing metrics response contract as much as possible; 3. add tests where one slow or unreachable Worker does not block the whole metrics request; 4. avoid changing unrelated job-status or scheduling behavior in the same PR. I also checked the GitHub assignment path, but this repository does not currently recognize `JeremyXin` as an assignable account. Please still feel free to proceed and open a PR against `dev`; link it back here once it is ready so the tracker is clear. -- 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]
