SEZ9 commented on issue #12345:
URL: https://github.com/apache/seatunnel/issues/12345#issuecomment-5704345961
Correction to the numbers in the issue body — I over-counted, and the
correction weakens my own argument, so I want it on the record before anyone
spends time on the lead.
**What I got wrong.** When `gh run rerun --failed` creates a new attempt,
GitHub carries the *unchanged* job records forward into that attempt: they
appear in `/actions/runs/<id>/attempts/<n>/jobs` with their previous conclusion
and, critically, an identical `started_at`/`completed_at`. I read those as
independent executions. They are not — a job only really ran in an attempt if
its `started_at` is distinct.
Filtering by distinct `started_at`, the real execution counts for
`all-connectors-it-1` are:
| Base | JDK 8 | JDK 11 |
|---|---|---|
| `75b60fa14` — #12298 | 1 real execution, 0 failures | **6 real, 5
failures** (a1–a5 fail, a6 pass) |
| `75b60fa14` — #12299 | 1 real execution, 0 failures | **3 real, 2
failures** (a1–a2 fail, a3 pass) |
| `75b60fa14` — total | **2 real, 0 failures** | **9 real, 7 failures** |
| `0d9f9e230` (pre-#11201) — #12298 | 1 real, 0 failures | 1 real, 0
failures |
So the two claims I made in the body do not survive:
- **"JDK 8: 8/8 legs pass" was wrong.** JDK 8 only ever executed the job
*once per run* — because it passed on the first attempt, `--failed` never
scheduled it again. The JDK-8-vs-JDK-11 asymmetry rests on **2** JDK 8 samples,
not 16. It is still suggestive that both passed while JDK 11 failed 7 of 9, but
it is nothing like the evidence I presented.
- **"0/8 before vs 6/8 after" was wrong**, for the same reason. The
pre-`#11201` side is **1 real execution per JDK**. A single pass before and 7/9
failures after is far too small a before-sample to locate a regression window,
so the `${testcontainer.version}` lead is now only weakly supported — treat it
as a guess, not a lead I have evidence for.
**What I still think is worth tracking**, stated with the sample size
attached: on `dev` @ `75b60fa14`, `NebulaGraphIT.startUp:109` (the
`adminPool.init(...)` assertion, ~9 s in, well inside the containers' declared
3-minute startup timeout) failed **7 of 9 real executions** of the JDK 11 leg
across two unrelated Zeta pull requests. That is a high enough rate to make
`all-connectors-it-1` unreliable for unrelated work, which is the practical
problem. Whether it is JDK-specific and whether #11201 is involved are both
open — I no longer have data that speaks to either.
Apologies for the noise; the methodology error was mine, and it inflated
every count in the original table.
--
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]
