SEPURI-SAI-KRISHNA commented on PR #12290: URL: https://github.com/apache/seatunnel/pull/12290#issuecomment-5912799920
Refreshed this branch onto current `dev`. The head was 54 commits behind and its CI evidence dated from September 21, so the red badge here was stale as well as, on the evidence below, unrelated to this change. The diff is untouched by the refresh: one file, `MultiTableSinkWriter.java`, +5/-7. No commit landed on `dev` touching that file since the merge base `ea3df166`, so the merge was conflict free and what you approved is what is here. **Both failures on the old run are pre-existing, and both already have open issues.** | leg | failing test | tracked by | | --- | --- | --- | | `engine-v2-it (8, ubuntu-latest)` | `SplitClusterFaultToleranceIT.testStreamJobCancelResolvesWhenWorkerCrashesBeforeCancelAck` | #12311, #12353 | | `engine-v2-it (11, ubuntu-latest)` | `BackpressureSlowSinkIT.testCheckpointsKeepCompletingUnderSustainedBackpressure` | #12313 | Neither is a whole-suite failure. JDK 8 finished `Tests run: 204, Failures: 0, Errors: 1, Skipped: 7`; JDK 11 finished `Tests run: 196, Failures: 0, Errors: 1, Skipped: 8`. Zero assertion failures on either leg, one Awaitility `ConditionTimeoutException` each. **Where the backpressure test died matters.** Its trace is `ConditionTimeoutException ... expected: <true> but was: <false> within 2 minutes` at `BackpressureSlowSinkIT.java:184`, caused by an `AssertionFailedError` at line 193. Line 193 is `Assertions.assertTrue(getLong(counts, "completed") >= 1L)`, inside the `atMost(2, TimeUnit.MINUTES)` block whose comment reads "Wait for the first checkpoint so the sampling loop below always starts from a well-defined baseline instead of racing the job's own startup". So the job never completed its first checkpoint, and the test died at its startup baseline before the backpressure loop ran at all. That is checkpoint-barrier startup, which is what #12313 is about, and it is upstream of anything a sink writer routes. **Neither test can reach the changed code.** `BackpressureSlowSinkIT` runs `stream_fast_fakesource_to_slow_inmemory_backpressure.conf`: `parallelism = 1`, one `FakeSource`, one `InMemory` sink, no table list. There is no multi-table routing to exercise and no second bucket to route to; the only "bucket" in that test is `bucket_ms`, a metrics window unrelated to `HashUtils.bucketIndex`. `SplitClusterFaultToleranceIT` is a Zeta cancellation test and does not touch `seatunnel-api` sink routing. **Both fail on unmodified `dev`.** @SEZ9 measured this on #12353: `SplitClusterFaultToleranceIT` failed 13 of 17 real executions across three code bases with no branch correlation, including a plain `dev` run, and every completed `dev` Build run since the test landed has had a red `engine-v2-it` leg. That comment also records the pair trading places, `BackpressureSlowSinkIT` failing on reruns where `SplitClusterFaultToleranceIT` passed. That is the pattern this PR's old run shows. Since #12311 and #12313 are both open, a rerun here will likely land on one of them again rather than come back green, so I would rather not keep rerunning. @nzw921rx @davidzollo if you agree the reds are unrelated, this is ready from my side. If you would rather wait for #12311 and #12313 to land first, say so and I will park it. -- 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]
