DanielLeens commented on PR #12163: URL: https://github.com/apache/seatunnel/pull/12163#issuecomment-5696129765
Thanks @SEZ9 — quick status update, since the branch actually already moved since the run you're referencing. **The sync already happened.** Head `01484485d` (the one behind `34791705815`) got merged with `dev` in commit `95a137ce7`, which picked up #12302. That's the current PR head. CI already reran on it (fork run [`34914656383`](https://github.com/zhangshenghang/seatunnel/actions/runs/34914656383), ~28h ago) — nobody had reported on it yet, so here's the breakdown of the failures on the synced head: - **`OpengaussCDCIT.testAddFieldWithRestore`** (`all-connectors-it-2`, both JDKs): same signature as before, still no overlap with `connector-cdc-base` or this PR's diff. Unrelated. - **`SplitClusterFaultToleranceIT.testStreamJobCancelResolvesWhenWorkerCrashesBeforeCancelAck`** (`engine-v2-it`, JDK 8 only this time): same CANCELED-vs-FAILED signature. This one's already root-caused as a worker-loss vertex-state race, independent of this PR — fix is up in #12311 (open, not yet merged into `dev`, hence still flaky). Zero call-chain overlap with `SeaTunnelSplitEnumeratorContext` or the CDC ack path. - **`BackpressureSlowSinkIT.testCheckpointsKeepCompletingUnderSustainedBackpressure`** — this is the one you flagged. It recurred, but on JDK 11 this time (was JDK 8 previously), same assertion shape (`expected at least 3 additional checkpoints ... only observed N`). I can rule out a regression here without a fresh repro: this is a known pre-existing engine race — the source reader can win an unfair monitor against the checkpoint barrier injector and starve barrier delivery under sustained backpressure. It's already root-caused with fixes open against `dev`: #12316 (the engine-side lock fix) and #12313 (a companion test-determinism fix), neither merged yet. The call chain is generic sink/checkpoint scheduling — it never touches `SeaTunnelSplitEnumeratorContext.sendEventToSourceReader` or anything in the CDC snapshot-split ack path this PR changes. So: confirmed pre-existing, not this PR. - **New in this rerun — `rocketmq-connector-it` (both JDKs)**: `RocketMqSourceSplitEnumerator` fails with "No topic route info in name server for the topic". This is on the Flink translation path (`FlinkSourceEnumerator`), unrelated to the Zeta enumerator-context change entirely, and this PR's diff doesn't touch any `rocketmq` files. This exact symptom has a history of stabilization attempts in `dev` (topic-route warming commits), so it's a known-flaky area, just not one that happened to fire in the previous rerun. Net: all four failures trace to pre-existing, independently-tracked issues (two with open fix PRs) with no diff overlap with this PR. Nothing here points back at the `sendEventToSourceReader`/ack-chain change. One thing worth flagging: the synced head (`95a137ce7`) is now 14 commits behind `origin/dev` again (fast-moving base), so I'd still do one more sync + rerun right before merge as a final sanity check — but I wouldn't expect new signal from it given the above. Your ask #3 (an end-to-end test for the restore-and-re-report path) is still open and is one for @zhangshenghang — my prior approval was on the source-side content and still stands; this comment is purely a CI-status update on the rerun that already happened. -- 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]
