DanielLeens commented on PR #12149: URL: https://github.com/apache/seatunnel/pull/12149#issuecomment-5678703339
Thanks for the heads-up, @CryoThrust — I checked this independently against the fork's actual run for `8fea514e` (run `34812493711`) rather than taking the summary at face value, and your diagnosis holds up. Breaking down what's actually failing: - **`engine-v2-it` (both JDKs)**: the two real test errors are `BackpressureSlowSinkIT.testCheckpointsKeepCompletingUnderSustainedBackpressure` (`ConditionTimeout`) and `SplitClusterFaultToleranceIT.testStreamJobCancelResolvesWhenWorkerCrashesBeforeCancelAck` (`ConditionTimeout`). Both are known, independently-root-caused dev-level flakes unrelated to `CheckpointCoordinator.java`'s scheduler-stop-after-cleanup change — `BackpressureSlowSinkIT` is a source checkpoint-lock starvation issue in the reader poll loop, and `SplitClusterFaultToleranceIT`'s cancel test is a pre-existing ~70% flake around `CancelTaskOperation` acking before a worker-loss is detected. Neither touches checkpoint-scheduler shutdown/cleanup. - **`all-connectors-it-2`**: `OpengaussCDCIT` failing — this is a currently-tracked dev-level CDC schema-restore regression (unrelated to Zeta's checkpoint coordinator), already has a fix in flight upstream. - **`rocketmq-connector-it`**: `RocketMqIT` with 14 failures/29 errors — matches the same "known container-timing flake" signature I called out in my last review on this exact PR (the pre-rebase run also failed there for unrelated reasons). - **`all-connectors-it-7`**: `S3FileConnectDryRunIT` failing — this one's worth flagging specifically: the fix for it (MinIO Docker Hub image was pulled/replaced, breaking the dry-run test's container) merged into `dev` as `0d9f9e2303d` at 2026-09-14T22:54:40Z — a few hours *after* your rebase (`8fea514e` was pushed at 06:07:08Z the same day). Your branch is now 9 commits behind `dev` (`compare dev...8fea514e` → `behind_by: 9, status: diverged`). Syncing to latest `dev` and rerunning CI should clear this specific lane. So: three of the four failing lanes are pre-existing/tracked dev-side issues a sync won't change (they're flaky/regressed independent of what commit you're on), and the fourth (`all-connectors-it-7`/S3) has a real fix already on `dev` that a sync would pick up. Given `mergeable: true` (no actual conflicts, just a routine 9-commit drift), I'd suggest going ahead and syncing — it'll get you a cleaner signal on `all-connectors-it-7` and won't hurt the others. No need for the empty-commit workaround. To be clear, this doesn't change anything about the review itself: my "Ready to merge after fixes" conclusion from the last round stands (the two non-blocking items — the Javadoc nit and the pre-existing race note), and I already independently corroborated on the pre-rebase SHA that none of the environmental failures touch `seatunnel-engine-server`. Once the synced head's CI settles, ping me and I'll do a final pass on that SHA. -- 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]
