DanielLeens commented on PR #11814: URL: https://github.com/apache/seatunnel/pull/11814#issuecomment-5846259786
Thanks for the follow-up. No new commit has landed since `ec6a7f9affc`, so I re-checked each of F1, F2/F3, and F4/F6 directly against the live source at that exact head rather than repeating what either of us said earlier — here's what's actually there right now. **F1.** I want to flag that this one was already closed in this thread: you wrote "I'm fine dropping the HIGH severity on that basis" back on 2026-09-19, after the `executeExtraCommands`-before-`start()` call-order trace, and I independently re-confirmed the same conclusion against this exact head on 2026-09-24. Nothing on `FakeSourceToConsoleWithEventReportIT.java` has changed since either of those comments. I just re-pulled the file again to be sure: lines 114-125 still install the `LogMessageWaitStrategy` on `.*received new worker register:.*` via `container.waitingFor(...)` inside `executeExtraCommands`, and that method is invoked before `server.start()` on this test's actual call path (`startUp()` -> `createSeaTunnelServer(NETWORK)`). So it is gating readiness correctly, and I don't think it's accurate to list this as HIGH/unaddressed again — if you're tracing a different code path than the one above, I'd genuinely like the specific line reference so I can re-check it, but as things stand this was resolved two rounds ago. **F2/F3.** Also unchanged and still resolved. I re-read `close()` line by line at `ec6a7f9affc` (`JobEventHttpReportHandler.java:214-270`): the final flush only executes `if (schedulerTerminated && !interrupted)` (line 238); when the scheduler doesn't stop in time or the wait was interrupted, the `else` branch just logs a warning and skips the flush entirely (line 261) — so there's no concurrent flush racing a still-running scheduled task. Both flush calls are wrapped in `catch (Exception e)` (lines 242 and 257), and the outer `finally` unconditionally runs `dispatcher().cancelAll()`, then `connectionPool().evictAll()`, then restores the interrupt flag if needed (lines 264-268). `close()` cannot throw on this path. **F4/F6.** Also unchanged and resolved. `seatunnel-engine-server/pom.xml:33-38` imports `kotlin-bom:1.9.10` into `dependencyManagement`, and the `kotlin-stdlib-jdk8` dependency at lines 112-115 declares no version, so it resolves through that BOM. I re-grepped both inventory files fresh just now: `tools/dependencies/known-dependencies.txt` and `seatunnel-dist/release-docs/LICENSE` each list `kotlin-stdlib`, `-common`, `-jdk7`, `-jdk8` at `1.9.10` only — no `1.8.21` entry in either file. **F5/F7/F8** — sounds good, take your time confirming those against the diff directly; nothing further needed from my side there. One thing worth surfacing that's new since my last comment: the fork's `Build` run for this exact head (`ec6a7f9affc`) has since finished, and it's `failure` this time rather than still queued. The job that matters for this PR is `engine-v2-it (11, ubuntu-latest)` — I pulled the full log, and the actual failure is `CheckpointCoordinatorFailoverIT.testStreamJobFailsAfterCheckpointTriggerDispatchFailure` in module 66/67 (`connector-seatunnel-e2e-base`), which has nothing to do with HTTP event reporting or okhttp3. Because the reactor isn't run with `-fae`, it stopped there and never reached module 67 (`connector-console-seatunnel-e2e`), so `FakeSourceToConsoleWithEventReportIT` and `HttpReportPackagingIT` — this PR's own tests — didn't get exercised at all in this run. The other three failing jobs (`unit-test (11, windows-latest)`, `doris-connector-it (8, ubuntu-latest)`, `transform-v2-it-part-1 (8, ubuntu-latest)`) are in modules this PR doesn't touch either. @goutamadwant — given the source-level items are all confirmed resolved above, the one open item is getting a completed `engine-v2-it` run that actually reaches the console E2E module on this head. Could you trigger a fresh run (or push if you end up making any further change) so we get a real pass/fail on the tests this PR owns? -- 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]
