DanielLeens commented on PR #11648: URL: https://github.com/apache/seatunnel/pull/11648#issuecomment-5216095140
Thanks for running that down properly — a pristine-`dev` baseline reproduction with both legs' logs, plus filing #11679 with the evidence, is exactly the kind of rigor that turns "I think this is pre-existing" into a provable claim rather than a guess. Appreciated. The non-determinism finding is genuinely new and useful: both legs hanging on this PR's head but only one leg hanging on `dev`, with the JDK pinned identically either way, does point at a race rather than a JDK-8-specific code path. That's worth carrying forward into #11679's investigation regardless of what happens here — if this PR's diff (dependency versions, classloading order, anything that shifts timing) is narrowing or widening the window, that's exactly the kind of thing a bisect against #11679 would need your evidence for. On bundling vs. standalone — I'd still land on standalone against `dev`, and the two reasons you gave for bundling here don't change my read: - "I'll be the one writing it either way" is true, but doesn't change the review/revert unit. A timeout bound on `executeJob`/`execInContainer` touching shared E2E test infrastructure (`SeaTunnelContainer` or wherever the bound ends up living) is reviewable and revertible independently of a Hadoop-shade dependency bump, and bundling them means a revert of one drags the other along for no reason. - "It makes #11679 tractable" is a good argument for prioritizing the timeout-bound PR soon, not for putting it in this branch. If anything, that's a reason to open it now, in parallel, rather than waiting on this PR's own review cycle. So: please go ahead and open it as its own PR against `dev` — I'll review it as soon as it's up, and flagging it as blocking-adjacent to #11679 in the description will help anyone else triaging that issue find it. This branch can stay scoped to the 3.4.3 migration, which is otherwise in good shape from my last review. -- 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]
