SEZ9 commented on issue #12345: URL: https://github.com/apache/seatunnel/issues/12345#issuecomment-5724550699
I went back over this with a method that does not depend on my earlier (retracted) tallies at all: reading `apache/seatunnel@dev`'s own `Build` runs and grepping each job log for this test class. It gives a much tighter answer, and it **restores the `#11201` lead I had downgraded to "a guess"** — this time on independent evidence. ### It is a dated regression on `dev`, reproducible with no pull request Most `dev` runs are `cancelled` by the next merge, but the ones that complete tell a clean story for `all-connectors-it-1`: | `dev` run | Date | Head | JDK 8 | JDK 11 | |---|---|---|---|---| | [34145973469](https://github.com/apache/seatunnel/actions/runs/34145973469) | 09-07 17:03 | `8bea8c681` | pass | pass | | [34801745423](https://github.com/apache/seatunnel/actions/runs/34801745423) | 09-14 03:11 | `46e58fc16` | pass | pass | | [34821874806](https://github.com/apache/seatunnel/actions/runs/34821874806) | 09-14 08:16 | `bd09f6d9a` | pass | pass | | [34935118103](https://github.com/apache/seatunnel/actions/runs/34935118103) | 09-15 06:01 | `f4a9665e8` | pass | pass | | [34995029902](https://github.com/apache/seatunnel/actions/runs/34995029902) | 09-15 16:26 | `1325a44b2` | **fail** | **fail** | | [35063682504](https://github.com/apache/seatunnel/actions/runs/35063682504) | 09-16 06:26 | `b37af3a9b` | pass | **fail** | | [35219017572](https://github.com/apache/seatunnel/actions/runs/35219017572) | 09-17 12:03 | `c7304ace6` | pass | **fail** | At class level, from the job logs: ``` 09-07 dev: [INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 205.782 s - in NebulaGraphIT 09-17 dev: [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.324 s <<< FAILURE! - in NebulaGraphIT [ERROR] NebulaGraphIT.startUp:109 expected: <true> but was: <false> ``` It is the only failing test in that job. 205 s when healthy, 8.3 s when broken — `startUp` aborts almost immediately, at ```java assertTrue(adminPool.init(Arrays.asList(new HostAddress(graphd.getHost(), graphd.getMappedPort(9669))), poolConfig)); ``` so all three containers report started and `NebulaPool.init` still returns `false`. The test file itself has not changed since 2026-08-30 (#11865), so nothing in the test moved. ### Window: `f4a9665e8...1325a44b2` — nine commits ``` a51712781 [Improve][CI] Run the seatunnel-cli Python test suite in CI (#12300) e86c03e53 [Feature][Connector-V2] Add PayPal Transaction Search source (#12282) 70a6720fc [Improve][E2E] Reuse SeaTunnel container for selected test classes (#11626) 60446da97 [Fix][E2E] Unify testcontainers version to 1.21.4 across all e2e connectors (#11201) 0b7fb5ddf [Feature][Connector-V2][LocalFile] Support append-only text tailing (#11819) 71a3c7518 [Feature][Firebase] sink connector (#12232) 3ad49cc2e [Docs][Connector-V2] Improve Paimon RocketMQ and Pulsar connector docs (#12187) 75b60fa14 [Fix][Connector-V2][Paimon] Register writer state serializer (#11978) 1325a44b2 [Docs] Add test class conventions to AGENTS.md (#12330) ``` **`60446da97` (#11201) is the prime suspect, and I owe an update on it.** In my retraction above I said the `${testcontainer.version}` / #11201 lead was "only weakly supported" once the inflated counts came out. It is now supported from a completely different direction. That commit does this to the root `pom.xml`: ```diff - <testcontainer.version>1.17.6</testcontainer.version> + <testcontainer.version>1.21.4</testcontainer.version> ``` and `seatunnel-e2e/seatunnel-connector-v2-e2e/connector-nebulagraph-e2e/pom.xml` consumes it: ```xml <groupId>org.testcontainers</groupId> <artifactId>junit-jupiter</artifactId> <version>${testcontainer.version}</version> ``` The commit touches 13 connector e2e poms and does **not** touch nebulagraph's — but nebulagraph inherits the property, so its testcontainers went 1.17.6 → 1.21.4 in this commit, four minor versions in one step, across code that decides when a container counts as ready. A `NebulaPool.init` that returns `false` seconds after the container reports started is exactly the shape of a changed readiness/port-mapping semantic. To be clear about the epistemic status: the version bump landing inside a nine-commit window is strong circumstantial evidence, not proof. It is now cheap to test, which it was not before. **Secondary suspect: `70a6720fc` (#11626), "Reuse SeaTunnel container for selected test classes."** It also touches no nebulagraph file, but it rewrites shared machinery every connector e2e module runs through — `SeaTunnelContainer`, `ContainerTestingExtension`, and a new `ReusableTestContainer` in `seatunnel-e2e-common` (+877/-42). Container lifecycle changes there can shift startup ordering for modules that never opted in. ### Two corrections to my own earlier framing - **Not JDK-11-only.** I reported 7 of 9 real JDK 11 executions with JDK 8 having run only twice. On `dev` the asymmetry is real but softer: since 09-15, JDK 11 has failed 3 of 3 while JDK 8 failed 1 of 3. So JDK 11 is hit harder, but JDK 8 is not immune, and the mechanism is a race rather than a JDK-specific defect. - **The regression date is 09-15, not "always broken."** It passed on `dev` at `f4a9665e8` that same morning. ### On #12329 @DanielLeens — your #12329 (retrying `NebulaPool` init to absorb graphd's status-versus-readiness gap) is a sensible mitigation regardless of cause, and if #11201 turns out to be the trigger it is arguably the correct permanent fix rather than a workaround: a newer testcontainers deciding "started" earlier is precisely a status-versus-readiness gap. You may want the window above for the PR description. I'm happy to bisect this properly — the window is only nine commits, and one control run on `60446da97~1` versus `60446da97` would settle it. Same technique I used to establish a base-level failure in #12353: a target commit plus a comment-only change so change detection schedules the job, read the one job, cancel, delete the ref. Say the word. -- 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]
