[Bug][E2E] NebulaGraphIT fails at startUp on the JDK 11 leg only, at a much higher rate since 2026-09-15

Search before asking

• I had searched in the issues and found no similar issues. (Searched NebulaGraph and testcontainers; nothing covering this.)

What happened

NebulaGraphIT fails in the all-connectors-it-1 job only on the JDK 11 leg, at NebulaGraphIT.java:109 — the assertTrue(adminPool.init(...)) in startUp, i.e. the three nebula containers start but the client cannot then connect to graphd. The JDK 8 leg of the same commit has never failed.

It is intermittent, not deterministic, so I want to be careful about what I claim. The observation that made me report it is a shift in rate around 2026-09-15, seen on two unrelated pull requests (#12298 and #12299, both Zeta changes that cannot reach a graph-database connector):

So: 0 failures in 8 JDK 11 legs before, 6 failures in 8 JDK 11 legs after, always at the same assertion.

A lead, explicitly not a proven cause. #11201 ("Unify testcontainers version to 1.21.4 across all e2e connectors") does not mention nebulagraph anywhere in its file list, but it changes one property in the root pom.xml:

-        <testcontainer.version>1.17.6</testcontainer.version>
+        <testcontainer.version>1.21.4</testcontainer.version>

and connector-nebulagraph-e2e/pom.xml:54 resolves its testcontainers dependency from ${testcontainer.version}. So this module was moved across four minor testcontainers versions without appearing in that PR's diff. NebulaGraphIT.startUp depends on container network aliases (--ws_ip=graphd, ADD HOSTS "storaged0":9779), which is an area where newer testcontainers releases changed defaults.

I have not bisected this, and the comparison is confounded: the two bases differ by more than #11201, and fork runner load differed substantially between the two rounds, which matters for a test that is timing-sensitive at startup. The version-inheritance point is a concrete thing to check first, not a diagnosis. If a maintainer can run all-connectors-it-1 on dev with testcontainer.version reverted to 1.17.6 for this module only, that would settle it quickly.

Whatever the cause, the JDK-8-vs-JDK-11 asymmetry looks like the most useful clue: the same containers, the same images, the same test, failing only on one JDK leg.

SeaTunnel Version

dev @ 75b60fa14 (3.0.0-SNAPSHOT); did not reproduce on 0d9f9e230.

SeaTunnel Config

Not applicable - this is an e2e test failure in CI during container setUp, before any
SeaTunnel job runs. The configuration is the one built into NebulaGraphIT.

Running Command

# As run by the all-connectors-it-1 job of the Build workflow:
./mvnw -B -T 1C verify -pl :connector-nebulagraph-e2e -am -DskipUT=true -DskipIT=false

Error Exception

[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.879 s <<< FAILURE! - in org.apache.seatunnel.e2e.connector.nebulagraph.NebulaGraphIT
[ERROR] org.apache.seatunnel.e2e.connector.nebulagraph.NebulaGraphIT  Time elapsed: 8.879 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
	at org.apache.seatunnel.e2e.connector.nebulagraph.NebulaGraphIT.startUp(NebulaGraphIT.java:109)

[ERROR] Failures:
[ERROR]   NebulaGraphIT.startUp:109 expected: <true> but was: <false>
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.22.2:verify (default) on project connector-nebulagraph-e2e: There are test failures.

Note the elapsed time: 8.9 s. The containers declare withStartupTimeout(Duration.ofMinutes(3)), so this is not a startup timeout — metad/storaged/graphd all reported started, and adminPool.init then returned false quickly.

Failing runs for reference: 34993525332 (JDK 11, all 4 attempts) and 34993534806 (JDK 11, attempts 1–2).

Zeta or Flink or Spark Version

Not relevant — the failure is in container/client setup before a job is submitted.

Java or Scala Version

JDK 11 (ubuntu-latest). JDK 8 on the identical commits passes.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

I'd rather not send a fix built on an unverified cause. If the testcontainers-version lead is confirmed by someone who can reproduce it, I'm happy to do the mechanical part.

Code of Conduct

• I agree to follow this project's Code of Conduct