DanielLeens commented on PR #11597: URL: https://github.com/apache/seatunnel/pull/11597#issuecomment-5412477063
Thanks for following up. Both questions were already answered in my most recent round (the Aug 24 15:05 UTC comment) — repeating and reconfirming here since the head hasn't moved since then (still `7c43aaf8fa7`, re-verified live just now via the PR API). 1. **CI outcome for the current head.** Still `Build: fail`. Re-checked live: same check-run I already cited (conclusion `failure`, completed `2026-08-24T00:17:37Z`, https://github.com/apache/seatunnel/runs/97126644419). The cause hasn't changed either: `seatunnel-engine-server` test-compile fails on `RunningJobSlotUsageBuilderTest.java:196` — `Mockito.doAnswer(...).when(ownedSlotProfilesMap).forEach(Mockito.any())` is ambiguous between `Iterable.forEach(Consumer)` and `IMap.forEach(BiConsumer)`. That one line breaks the reactor's shared test-compile step, which is why every job in the matrix is red, not just unit-test. Fix is mechanical — give the mock a generic type witness, e.g. `Mockito.<BiConsumer<PipelineLocation, Map<TaskGroupLocation, SlotProfile>>>any()`. This is a High/blocking item; the bottom line is unchanged from Aug 24: not ready to merge until it compiles and a fresh run goes green. 2. **Status of Issues 2 and 3 from the Aug 22 round.** Both closed, as stated in my Aug 23 comment: - Issue 2 (`getCoordinatorService()` called per running job, could sleep up to 1.5s/call) — fixed. `build(SeaTunnelServer)` now resolves `CoordinatorService` once before the loop instead of inside it. - Issue 3 (aggregation running inline on a shared Hazelcast operation thread) — not reproducible at `7c43aaf8`. `GetRunningJobSlotUsageOperation.run()` already offloads via a dedicated executor (`getExecutor("get_running_job_slot_usage_operation")`), matching the `GetRunningJobMetricsOperation` sibling. I retracted it in the Aug 23 round rather than carry it forward as unresolved. What's still open on the code side (separate from the compile break) is the narrower finding from Aug 23/24: `slotSourceAvailable` only detects the all-empty, cluster-wide staleness case, not per-job partial staleness — a specific job can show `slotCount: 0, slotSourceAvailable: true` while just that job's slot data hasn't round-tripped into the resource manager snapshot yet. That's Medium, tracked as Issue 2 in my Aug 24 comment. So the bottom line is unchanged since Aug 24: **not ready to merge** — the compile failure blocks any CI signal at all, and the per-job staleness gap in `slotSourceAvailable` is the one substantive Medium item once that's fixed. Once a fix for the `forEach` ambiguity is pushed, I'll re-trace against the new head. -- 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]
