loustler commented on PR #11648: URL: https://github.com/apache/seatunnel/pull/11648#issuecomment-5209985467
@DanielLeens the pristine-`dev` baseline run finished, and the answer is: you were right. I pushed `origin/dev` with nothing but a three-line comment (added only so the `changes` filter would schedule `paimon-connector-it`) and ran the job. `PaimonWithS3IT` hangs there too, with none of this PR's changes present: | leg | result | |---|---| | JDK 11 | passed — `Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 118.481 s` | | JDK 8 | started, no result line, killed at the 180-minute timeout | In the JDK 8 log, after `PaimonWithS3IT` starts there are 5 occurrences of `/fake_to_paimon_with_s3_with_privilege.conf` and 2 of `/paimon_to_paimon_with_s3_with_privilege.conf`, then `##[error]The operation was canceled.` On that same leg `PaimonIT` finished normally (`Tests run: 26 ... 1,206.934 s`), so this was not a slow runner. So your read — pre-existing engine behaviour that this PR merely made reachable — holds, and your decision not to attribute it to this diff without proof was the correct call. I've filed it as #11679 with the evidence, credited to you. One thing your analysis didn't have, which I think matters: **it is not deterministic.** You observed it on both legs on this PR's head; on `dev` only one of the two legs hangs. The E2E harness pins `seatunnelhub/openjdk:8u342` regardless of the matrix leg, so the SeaTunnel process is on the same JDK either way and the difference between legs is timing, not a JDK-specific path. That suggests a race. Whether this PR widens it is an open question I can't answer yet — I tried to reproduce locally to get a thread dump of the blocked client and could not: SeaTunnel pins Testcontainers 1.17.6, which negotiates Docker API 1.32, and the daemon I have available requires 1.40+. Which leads to Option B, and I'd like to argue for it slightly differently than as a stopgap for this PR. Since the hang is on `dev`, `dev`'s own `paimon-connector-it` is exposed to the same 180-minute burn today. Bounding `executeJob` in these tests is therefore worth having on its own terms, not as something this branch does to get itself green — and it also makes #11679 tractable, because measuring how often the hang occurs is only affordable once a recurrence costs seconds instead of three hours. I'll add that bound here. Let me know if you'd rather see it as a standalone PR against `dev` instead, given the above — I'm happy either way, and there's a reasonable argument that it belongs there rather than in a dependency-upgrade branch. -- 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]
