SEPURI-SAI-KRISHNA commented on PR #12495:
URL: https://github.com/apache/seatunnel/pull/12495#issuecomment-6057544654
Build triage for the run at `8c7553d27`, which is what the red badge here
has shown since 10-05. None of it is attributable to this change. The head has
since moved to `4b2cd492e` and run `37759695509` is in flight on it; I will
report that separately rather than let this stand in for it.
Run `37272080837`: 80 success, 2 failure, 1 cancelled, 11 skipped. The run
itself is `completed/cancelled`.
**`engine-v2-it (11)` was never a test failure.** The step list settles it
without the log:
```text
[cancelled] 5. run seatunnel zeta integration test
[skipped] 6. Upload test reports
```
The test step was cancelled, not failed. It ran 29.7 of a 150 minute limit,
and the upload step being skipped is why no test-report artifact exists for
this leg and why its log ends mid-stream. Nothing to diagnose; it needs
re-running.
**`Build website` is the 90 minute wall.** 90.3 minutes against
`timeout-minutes: 90`, recorded as cancelled. That is exactly what #12614
fixed, and #12614 is now in `dev`, so a rebase clears this one.
**`unit-test (8, ubuntu-latest)` is the only real failure.** From its
`test-reports` artifact, 1 error in 7808 tests:
```text
SavePointTest.testSavePointButJobGoingToFail
ConditionTimeoutException ... expected: <RUNNING> but was: <FAILED> within
2 minutes
```
That message is inverted. The assertion is
`assertEquals(getJobStatus(jobId), JobStatus.FAILED)`, actual first and literal
second, so the job **stayed RUNNING** and never reached `FAILED` inside the 120
second window. The opposite of how it reads.
**Not reachable from this PR.** The diff is seven `src/main` files, all under
`seatunnel-transforms-v2/.../transform/sql/`, plus four test classes in the
same module. The
failing test lives in `seatunnel-engine-server`, and
`stream_fake_to_inmemory_with_error.conf`
declares an **empty** `transform { }` block, so no SQL transform is on that
job's path at all.
I did not find an issue tracking this one. #12441 is adjacent, same class
area, but it is someone
else's report about `startSavepoint` holding the coordinator lock and it
names neither this test
nor this symptom. So I am reporting it here as triage rather than calling it
a known flake, and I
am happy to file it separately if you would like it tracked.
Next step on the CI side is a rebase onto current `dev`, which picks up
#12614 and should leave a clean matrix to judge the `SavePointTest` timing
failure against.
--
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]
