wombatu-kun opened a new pull request, #8940: URL: https://github.com/apache/paimon/pull/8940
### Purpose `PrimaryKeyFileStoreTableITCase` can hang until the 120-minute cap of the "UTCase and ITCase Flink 2.x on JDK 11" job. Since GitHub reports a job timeout as `CANCELLED` rather than a failure, and a killed job leaves behind neither a surefire report nor artifacts, this reads as if someone had cancelled the run. It happened twice on clean master in the last two days (runs 30420293991 and 30327861765) and also on unrelated PR branches. In each case this class was the only one that logged `Running ...` and never reported completion, against a normal runtime of about 537 s for its 30 tests. The unbounded wait lives in `checkBatchResult`. #7036 added a `while (true)` loop that waits until `T$files` reports no level 0 files, for tables where `needLookup()` holds, that is a lookup changelog producer or deletion vectors. If compaction never completes, the loop spins forever: in `testStandAloneLookupJobRandom` the table is `write-only` and compaction is performed by a separate `CompactAction` job, so a dead compactor makes the condition unsatisfiable. `@Timeout(180)` does not rescue the test, because JUnit 5.8.1 in SAME_THREAD mode delivers a single `Thread.interrupt()`, and the loop spends nearly all of its time inside a Flink job where that interrupt is lost. #4634 had already introduced the `collect(result, timeout)` watchdog helper for exactly this class of problem, and the next statement in the same method uses it, but the loop added later calls `TableResult.collect()` directly and bypasses it. This change bounds the wait by `TIMEOUT` seconds, routes the query through the existing watchdog helper, and reports how many level 0 files were still present when the deadline expired. A stalled compaction now fails in about three minutes with a message that separates "compaction is dead" from "compaction is slow", instead of consuming the entire CI job. The deadline equals the value these tests are already annotated with, so no test becomes stricter than it was meant to be. ### Tests Ran the eight `*Random` tests that reach `checkBatchResult` under `-Pflink2` on JDK 11: `Tests run: 8, Failures: 0, Errors: 0` in 149 s. Negative check, to confirm the deadline actually fires instead of being dead code: with the loop condition temporarily made unsatisfiable and the deadline shortened, the test failed after 46 s with `java.util.concurrent.TimeoutException` reporting 16 remaining level 0 files, rather than hanging. That temporary modification is not part 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]
