DanielLeens commented on PR #11746:
URL: https://github.com/apache/seatunnel/pull/11746#issuecomment-5451457564
Thanks for the detailed failure matrix, @li3zhi4 — I went and pulled the raw
logs for the fork's `Build` run `32099067143`, attempt 6 (completed
`2026-08-25T06:09:26Z`, head `2debe857f`) myself rather than going off
summaries, and I don't think this is the kind of infra flake that a
maintainer-triggered rerun (or an exemption) will fix — I found the actual root
cause, and it's deterministic, not random.
**What's actually happening:** every attempt where `JdbcOracleSplitIT` gets
far enough to try starting its container fails with the exact same error,
verbatim, in attempt 6:
```
ERROR 🐳 [gvenzl/oracle-xe:21-slim-faststart] - Could not start container
com.github.dockerjava.api.exception.NotFoundException: Status 404:
{"message":"No such image: gvenzl/oracle-xe:21-slim-faststart"}
...
org.testcontainers.containers.ContainerLaunchException: Container startup
failed
Caused by: org.rnorth.ducttape.RetryCountExceededException: Retry limit hit
with exception
Caused by: org.testcontainers.containers.ContainerLaunchException: Could not
create/start container
Caused by: com.github.dockerjava.api.exception.NotFoundException: Status
404: {"message":"No such image: gvenzl/oracle-xe:21-slim-faststart"}
```
That's a 404 on the image tag itself (Docker can't resolve/pull it), not a
timeout, not a resource-contention or registry-rate-limit error. It's the same
failure in attempt 1 ("image 404" in your table) and attempt 6 (what I just
re-verified) - it's not intermittently succeeding and occasionally failing, it
never once got past container creation across all 6 attempts.
**Why only this test, and not the rest of the module:**
`JdbcOracleSplitIT.java` (this PR's new file) hardcodes:
```java
private static final String ORACLE_IMAGE =
"gvenzl/oracle-xe:21-slim-faststart";
...
DockerImageName imageName = DockerImageName.parse(ORACLE_IMAGE);
```
But the pre-existing sibling test in the very same module,
`JdbcOracleIT.java`, already migrated off that tag a while ago:
```java
private static final String ORACLE_IMAGE =
"gvenzl/oracle-free:slim-faststart";
...
// gvenzl/oracle-free is a multi-arch (amd64/arm64) substitute for
gvenzl/oracle-xe
DockerImageName imageName =
DockerImageName.parse(ORACLE_IMAGE).asCompatibleSubstituteFor("gvenzl/oracle-xe");
```
That's why `JdbcOracleIT`/`JdbcOracleMultipleTablesIT` and the rest of the
Oracle E2E suite are passing on these exact runners while only the new
`JdbcOracleSplitIT` 404s - they're pulling a different, currently-resolvable
image tag. `gvenzl/oracle-xe:21-slim-faststart` looks to no longer be a valid
pull target from this runner network, which is exactly why `dev` already
carries the `oracle-free` substitution with that explanatory comment.
**Concrete next step:** update `JdbcOracleSplitIT.java`'s container
bootstrap to match `JdbcOracleIT.java` exactly - switch `ORACLE_IMAGE` to
`"gvenzl/oracle-free:slim-faststart"` and wrap it with
`.asCompatibleSubstituteFor("gvenzl/oracle-xe")` before constructing
`OracleContainer`. That's a one-line, test-only image-tag change in a file this
PR itself introduces, so it doesn't touch the composite-key logic at all. Once
that's pushed, a rerun should actually get past container startup instead of
404ing again - rerunning the current head as-is won't help, since it'll hit the
identical 404 every time regardless of how many attempts you spend on it.
On `JdbcMysqlSplitIT` (part-2 (8)): I checked that job too - it's not
independently flaking, it's a plain GitHub Actions matrix cancellation. `part-2
(8)` and `part-2 (11)` are sibling legs of the same
`updated-modules-integration-test-part-2` matrix; when the `part-2 (11)` leg
(Oracle) fails, Actions' default fail-fast cancels `part-2 (8)` as a side
effect - the job's only step shows `conclusion: cancelled`, not a test failure.
Once the Oracle image fix lands and that leg goes green, `part-2 (8)` should
get a real chance to run, and given your reported local 1/1 pass for
`testCompositeKeyWithStringColumn`, I'd expect it to go green on the first try.
I wouldn't frame this as an "infra-flake exemption" case, since it's 100%
reproducible on the current head rather than intermittent - but it is a small,
test-only fix, so I'd expect this to clear quickly once pushed. I'm holding off
on a fresh full review since there's no new commit yet; once the image-tag fix
(and hopefully a completed green run for
`JdbcMysqlSplitIT`/`JdbcOracleSplitIT`) lands, I'll re-derive the review
against that head as usual, per Issue 1 from my last round.
--
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]
