SEZ9 commented on PR #12299:
URL: https://github.com/apache/seatunnel/pull/12299#issuecomment-5707438132
## CI status after four more rerun rounds
I reran the failed jobs four more times (attempts 5–8). Nothing new turned
green, and the remaining red is now accounted for by experiment rather than by
assertion.
**Final state:** `all-connectors-it-2 (8, 11)` and `engine-v2-it (8)`.
### `engine-v2-it (8)` — I checked whether this one was mine, and it is not
This is the one I owed real work on, because this PR touches
`seatunnel-common/FileUtils` and `seatunnel-engine-server`, and the job failed
**8 out of 8 real executions** here while passing on #12298. The failing test
is always:
```
SplitClusterFaultToleranceIT.testStreamJobCancelResolvesWhenWorkerCrashesBeforeCancelAck:448
-> assertEventuallyCanceled:556 » ConditionTimeout
expected: <CANCELED> but was: <FAILED>
```
Note what that assertion says: the job *does* reach a terminal state, it is
simply the wrong one. This is not a hang or a timeout in the cancel path.
**Control experiment.** Rather than argue from my diff, I pushed a throwaway
branch that is this PR's exact base `75b60fa14` plus a three-line comment in
`seatunnel-engine/README.md` — enough for change detection to schedule
`engine-v2-it`, and nothing else. Result ([run
35166337277](https://github.com/SEZ9/seatunnel/actions/runs/35166337277), JDK
8):
```
[ERROR]
SplitClusterFaultToleranceIT.testStreamJobCancelResolvesWhenWorkerCrashesBeforeCancelAck:448
->assertEventuallyCanceled:556 » ConditionTimeout
[ERROR] Tests run: 203, Failures: 0, Errors: 1, Skipped: 6
```
Same test, same line, same assertion, with **none of this PR's code
present**. The JDK 11 leg of that same control run passed, matching the JDK 11
behaviour here.
This is also filed upstream independently: **#12353**, reproduced there on
unmodified `dev` @ `6ee0c374` with JDK 17. My control adds the JDK 8 / Linux
data point. The suspected terminal-state path in that issue is
`SubPlan.getPipelineEndState()` / `addPhysicalVertexCallBack()` — nothing this
PR goes near.
One thing I cannot explain and would rather flag than paper over: #12298, on
the same base, passed this test on all 3 of its real executions. The only
correlation I can see is suite composition — the base and this PR both run 203
tests in that module and fail, while #12298 runs 204 (it adds a `RestApiIT`
case) and passes. For a test that is a deliberate race between a cancel request
and a worker shutdown, ordering and timing shifts are a plausible mechanism,
but I have not tested that and am not claiming it.
### `all-connectors-it-2 (8, 11)` — #12344
`OpengaussCDCIT.testAddFieldWithRestore` is now at **40 failures in 40 real
executions** across two unrelated PRs, two bases, and both JDKs, with no pass
ever observed. Tracked as #12344. Rerunning does not clear it.
### What this PR's own changes do in CI
All green, on the first real compile of them:
| | Linux JDK 8 | Windows JDK 8 |
|---|---|---|
| `FileUtilsTest` | 14 run, 0 failures | 14 run, 0 failures |
| `LogContentReaderTest` | 3 run, 0 failures | 3 run, 0 failures |
| `YamlSeaTunnelConfigParserTest` | 4 run, 0 failures | 4 run, 0 failures |
| `RestApiIT` | 22 run, 0 failures, **0 skipped** | — |
The Windows leg matters here specifically: it is what exercises the review
points about decoding UTF-8 rather than the platform default charset, and about
the truncation notice using a literal `\n` rather than `%n`.
### A methodology correction that affects numbers I posted earlier
When `rerun --failed` creates a new attempt, GitHub carries the jobs it did
*not* re-execute forward into that attempt with their old conclusion and an
identical `started_at`. I had been counting those as independent executions,
which inflated several tallies I quoted on these PRs and in #12345 (retracted
there). Every count in this comment is deduplicated by distinct `started_at`.
--
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]
