SEZ9 commented on PR #12298:
URL: https://github.com/apache/seatunnel/pull/12298#issuecomment-5693944596
## CI status on the current head (`d671c5d86`)
Rebased onto `75b60fa14` — content unchanged, replayed onto a newer `dev` to
pick up `[Fix][E2E] Unify testcontainers version to 1.21.4` (#11201) and
`[Improve][E2E] Reuse SeaTunnel container for selected test classes` (#11626),
on the chance they affected the e2e container failures below. The patch is
byte-identical before and after the replay.
**This PR's own test is green.** `engine-v2-it`'s `RestApiIT` reports 23
run, 0 failed, 0 errors, 0 skipped on both JDK legs, so
`testDynamicHttpPortIsResolvableByPeers` genuinely ran and passed — the
surefire summary does not name individual passing tests, but `Skipped: 0` rules
out it having been quietly skipped. `unit-test` is green on all four legs. This
is the first real compile of the `volatile` change; I have no JDK locally and
said so rather than implying I had verified it.
**What is still red, and why I stopped rerunning.** After four attempts the
failure set stopped changing:
| Job | Failing test | Error |
|---|---|---|
| `all-connectors-it-2` (8 and 11) |
`OpengaussCDCIT.testAddFieldWithRestore` | `ConditionTimeout` at
`OpengaussCDCIT.java:476` — `actual iterable was <null> at index [1][4] within
1 minutes` |
| `all-connectors-it-1` (11) | `NebulaGraphIT.startUp:109` | `expected:
<true> but was: <false>` |
This diff touches `JettyService`'s constructor and one `HttpConfig` field.
Neither failure is reachable from it. Evidence rather than assertion:
- `OpengaussCDCIT.testAddFieldWithRestore` fails identically on **#12299** —
an unrelated Zeta PR touching the REST log endpoints, not CDC — on both JDKs,
before *and* after the rebase, on every attempt across both branches. It has
not passed once in this fork's runs. No upstream issue exists for it yet (I
searched for both `OpengaussCDCIT` and `testAddFieldWithRestore`).
- `NebulaGraphIT` is more interesting, and I think it is worth a
maintainer's attention independently of this PR. It did **not** fail on either
of my branches before the rebase, and started failing on **both** immediately
after they were replayed onto a `dev` containing #11201. The mechanism fits:
#11201's diff does not mention `nebulagraph` at all, 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 that module was moved across
four minor versions of testcontainers without appearing in the PR's file list.
The failure is at `NebulaGraphIT.java:109`, `assertTrue(adminPool.init(...))`:
the three nebula containers (`metad`/`storaged`/`graphd`) start, but the client
cannot then connect to `graphd`. That test depends on container network aliases
(`--ws_ip=graphd`, `ADD HOSTS "storaged0":9779`), which is precisely the area
newer testcontainers releases changed defaults in.
I have not bisected this, so treat it as a well-supported hypothesis
rather than a proven cause — but since it appears to affect every PR whose
change set touches `all-connectors-it-1`, not just this one, it seemed worth
writing down here.
I have stopped issuing reruns: the failure set is deterministic and further
attempts only consume the fork's runner quota (7–9 hours per full run here,
mostly queueing). Happy to rerun or rebase again on request.
To restate the one open review item so it does not get lost: I took Issue 2
(`volatile`) and explained in my previous comment why I believe Issue 1's
`incompatible-changes.md` entry does not apply here — `HttpConfig.getPort()` is
an internal accessor and the only user-visible effect is that a broken endpoint
now works, so there is nothing for a user to migrate. If a maintainer disagrees
I will add the entry without further argument.
--
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]
