SEPURI-SAI-KRISHNA commented on PR #11724:
URL: https://github.com/apache/seatunnel/pull/11724#issuecomment-5238752592
Following up with the actual failing test, and with a correction to my last
comment.
**Correction first:** I said "the failure moves." That was wrong. The run
for `ff47430b` failed in `seatunnel-engine-server` on Windows JDK 8 again — the
same module as the previous run, not a different one. Only the first of the
three failures was elsewhere (`seatunnel-api`). I shouldn't have generalised
from two data points.
**The failing test, which is what you asked for:**
```
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
311.203 s <<< FAILURE!
- in
org.apache.seatunnel.engine.server.dag.physical.StateTransitionCleanupTest
[ERROR]
org.apache.seatunnel.engine.server.dag.physical.StateTransitionCleanupTest
Time elapsed: 311.203 s <<< ERROR!
java.lang.IllegalStateException: Node failed to start!
```
It is a Hazelcast member failing to bootstrap, after hanging for 311
seconds. The same job log also opens with `ERROR Unable to create Appender of
type File`, i.e. log4j could not create its log file on the Windows runner. For
comparison, that test class on my machine:
```
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.815 s
- in
org.apache.seatunnel.engine.server.dag.physical.StateTransitionCleanupTest
```
1.8 seconds and 3 tests locally, versus 311 seconds and a node that never
came up on the runner. That is an environment failure — a cluster member timing
out during startup on a contended Windows agent — not a test asserting
something wrong about the code.
**Why it cannot be this PR**, independent of the above:
`seatunnel-engine-server` has no dependency on `seatunnel-transforms-v2`,
direct or transitive:
```
$ ./mvnw -pl seatunnel-engine/seatunnel-engine-server dependency:tree \
-Dincludes=org.apache.seatunnel:seatunnel-transforms-v2
(no matches)
```
`ZetaSQLFunction` is not on that module's classpath, so no change to it can
reach `StateTransitionCleanupTest`. The full module suite is also green here on
this exact head: `Tests run: 380, Failures: 0, Errors: 0, Skipped: 5`.
And on the same commit `ff47430b`, `unit-test (11, windows-latest)`
**passed** while `unit-test (8, windows-latest)` failed — same code, same OS,
same runner image, differing only in JDK. A defect in decimal arithmetic would
not be JDK-specific.
**Two things I want to be straight about rather than let you find them:**
- This job passed on #11721's run yesterday, so it is not simply broken for
everyone all the time. It is intermittent, and it has now hit this branch twice
in a row, which is worse luck than I would like to be arguing from.
- My local runs are JDK 11 on Linux; this machine has no JDK 8, so I cannot
reproduce the failing configuration directly. The module-dependency argument
above is the one that does not depend on reproducing it.
In each run the other `unit-test` legs show `cancelled` within seconds of
the failure — matrix fail-fast, so it is one failure rather than three.
Happy to open a separate issue for the flaky `StateTransitionCleanupTest`
startup on Windows JDK 8 if that would be useful; it looks like a pre-existing
infrastructure problem that will keep costing other contributors CI cycles, and
it is clearly outside the scope of this PR.
--
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]
