DanielLeens commented on PR #12391: URL: https://github.com/apache/seatunnel/pull/12391#issuecomment-5787086018
@SeaSand1024 @SEZ9 thanks for the detailed re-run breakdown — this is exactly the kind of evidence that lets us close this out without guessing. I re-checked first: head is still `0fc63dc5`, and the diff against my last review is unchanged (same three files), so nothing below required a fresh code review, just triage of the four red jobs. Good news first: **`OpengaussCDCIT.testAddFieldWithRestore` (`all-connectors-it-2`, both JDKs) should clear with a `dev` sync.** That failure's real root cause was found and fixed in [#12346](https://github.com/apache/seatunnel/pull/12346) ("Preserve disabled CDC schema behavior"), which merged into `dev` on 2026-09-20 — it's the fix for the exact issue you both were tracking as [#12344](https://github.com/apache/seatunnel/issues/12344). This branch is currently 24 commits behind `dev` (per the compare view), so it predates that fix, which is why your fork re-run still hits it. Unlike the other three jobs below, this one is not "wait for an open PR" — the fix is already on `dev`. @SeaSand1024, could you sync/merge latest `dev` into this branch (no need for a full rebase, just picking up `dev` HEAD is enough) and re-run `all-connectors-it-2`? I'd expect it to go green. The other three failures are pre-existing `dev`-level flakes, none of them touching the code this PR changes, and none of them fixed yet: - **`SplitClusterFaultToleranceIT.testStreamJobCancelResolvesWhenWorkerCrashesBeforeCancelAck`** (`engine-v2-it`, JDK 8) — this is the known CANCELED-vs-FAILED race tracked in [#12353](https://github.com/apache/seatunnel/issues/12353). The fix ([#12311](https://github.com/apache/seatunnel/pull/12311)) is still open, not merged, so syncing `dev` won't clear this one — same conclusion as my last comment, just re-confirmed live. - **`CheckpointCoordinatorFailoverIT.testStreamJobFailsAfterCheckpointTriggerDispatchFailure`** (`engine-v2-it`, JDK 11) — this is a new one for this thread, but it's a known racy fault-injection timing issue in the test itself (the readiness gate it uses can fire before the checkpoint it's supposed to target has actually completed, so the injected fault can land on either checkpoint and surface as different symptoms, including the `taskGroupLocation` lookup failure you saw). A fix for the test's fault-injection ordering is open in [#12288](https://github.com/apache/seatunnel/pull/12288), not yet merged. Nothing in this PR's diff touches `CheckpointCoordinator` or barrier/notify dispatch, so I don't read this as caused by this change. - **`BackpressureSlowSinkIT.testCheckpointsKeepCompletingUnderSustainedBackpressure`** (`engine-v2-it`, JDK 11) — known checkpoint-lock-starvation flake under sustained backpressure. Fixes are open in [#12316](https://github.com/apache/seatunnel/pull/12316) (engine fix) and [#12313](https://github.com/apache/seatunnel/pull/12313) (test-only, complementary), neither merged yet. So: sync `dev` and re-run `all-connectors-it-2` — that should turn green. The two `engine-v2-it` (JDK 11 leg gets both `CheckpointCoordinatorFailoverIT` and `BackpressureSlowSinkIT`; JDK 8 gets `SplitClusterFaultToleranceIT`) failures will very likely stay red until #12311, #12288, and #12316/#12313 land, since none of those are in `dev` yet. That's a judgment call for whoever merges this: the code side has been ready since my last review, and all four red jobs are now attributed to specific, tracked, pre-existing issues rather than anything in this diff — a committer could reasonably merge on the green unit-test matrix plus this attribution once the Opengauss job is confirmed green post-sync, without waiting for the other three upstream fixes. No further code-side asks from me. Thanks again for staying on top of the CI noise instead of folding unrelated fixes in — that made this easy to untangle. -- 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]
