DanielLeens commented on PR #11458: URL: https://github.com/apache/seatunnel/pull/11458#issuecomment-5548368028
## CI follow-up on the current head (`a71c68c426f8`) My last review (2026-09-04T10:38:12Z) noted 2 jobs still in progress on the fork's Build run (`33854690642`) and said I'd expect to re-affirm `APPROVED` once they completed. They have completed now, but the overall `Build` check is red — not because of those two, though: it's 3 different jobs, and I traced each one to root cause rather than assuming the obvious "flaky E2E" label: 1. **`doris-connector-it (8, ubuntu-latest)` — failed.** Root cause: `Could not transfer artifact com.google.protobuf:protobuf-java:jar:3.19.4 from/to central ... Connection reset`. Pure Maven Central network flake during dependency resolution, before any test even ran. Unrelated to this PR. 2. **`jdbc-connectors-it-part-7 (8, ubuntu-latest)` and `(11, ubuntu-latest)` — both failed**, same root cause on both JDK versions: `org.apache.seatunnel.connectors.seatunnel.jdbc.MetalakeIT.startUp` — `org.awaitility.core.ConditionTimeoutException: expected: <0> but was: <7> within 3 minutes`. This is a pre-existing readiness-timing issue in the Metalake catalog IT test itself, not something this PR's diff touches. 3. `kudu-connector-it (8/11)` show as cancelled, which is just the workflow's fail-fast cancellation once the above jobs went red — not an independent failure. I confirmed none of these three job's underlying modules appear in this PR's file list at all (`git diff --name-only` against this head: `docs/*`, `connector-rocketmq/*` (source + the two E2E test files already discussed in prior rounds), `seatunnel-engine-server/*` main+test). Nothing under `connector-doris-e2e` or `connector-jdbc-e2e-part-7` is touched. I also checked whether `dev` already carries a fix for the `MetalakeIT` timeout that this branch just hasn't synced yet — it doesn't; this looks like a standing flaky/slow test on `dev` itself, unrelated to this PR, and not something I'm going to paper over with a blind timeout bump without someone actually root-causing why the catalog isn't converging in 3 minutes. **Conclusion: this Build failure is not a blocker for this PR.** Both failing modules are outside this PR's diff and the failures reproduce for reasons (network transfer reset, pre-existing catalog-readiness flakiness) that have nothing to do with fixed-slot failover reuse. My substantive review verdict from Sept 2 (`APPROVED`, mechanism sound) still stands. @zhangshenghang, a CI re-run should clear both — no code change needed on your side for this. The one item still keeping this PR from merge is the same one from every recent round: `mergeStateStatus: BLOCKED` / `reviewDecision: REVIEW_REQUIRED` needs an approval from an account with write access to `apache/seatunnel`, since mine doesn't count toward that gate. -- 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]
