GabrielBBaldez opened a new issue, #12045: URL: https://github.com/apache/seatunnel/issues/12045
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22bug%22) and found no similar issues. ### What happened `CoordinatorServiceTest.testPendingJobSchedulerCanAdvanceNextJobWhenPreviousResourceCheckBlocks` fails intermittently on Java 8 runners: ``` [ERROR] testPendingJobSchedulerCanAdvanceNextJobWhenPreviousResourceCheckBlocks Time elapsed: 0.056 s <<< ERROR! java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@5c936b5f rejected from java.util.concurrent.ThreadPoolExecutor@5c2fc86[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 1] at org.apache.seatunnel.engine.server.CoordinatorServiceTest.invokePendingJobScheduler(CoordinatorServiceTest.java:771) at org.apache.seatunnel.engine.server.CoordinatorServiceTest.testPendingJobSchedulerCanAdvanceNextJobWhenPreviousResourceCheckBlocks(CoordinatorServiceTest.java:598) ``` This is the sibling of the test stabilised in #12013 / #12012, in the same class, but a different mechanism — so the fix there does not cover it. ### Mechanism `startPendingJobScheduleThread()` submits to the **shared** `executorService` rather than creating its own: ```java executorService.submit(pendingJobScheduleTask); ``` The test calls `invokePendingJobScheduler` twice on purpose — once for the blocked scheduler, then again to show a new generation can advance past it. By the second call the pool reports `Terminated` with `completed tasks = 1`, so something between the two invocations shut the shared executor down and the second submit is rejected. `completed tasks = 1` is the tell: exactly one task had run, so the executor was alive for the first invocation and dead for the second. Since `CoordinatorServiceTest` shares the coordinator across its methods, the likely culprit is a sibling test's cleanup — the class calls `shutdownNow()` on the coordinator's schedulers — reaching the executor this test still needs. ### What you expected to happen The second `invokePendingJobScheduler` submits successfully, and the test asserts on scheduler generations rather than dying on executor state. ### How to reproduce Intermittent, and load-dependent — it surfaced on `unit-test (8, ubuntu-latest)` and not on the JDK 11 legs of the same run. Repeatedly running the whole `CoordinatorServiceTest` class on a constrained machine is the way I would try to reproduce it, since it appears to depend on a neighbouring test rather than this one alone. ### SeaTunnel Version `dev` at 1d18735b. ### Are you willing to submit PR? - [X] Yes I am willing to submit a PR! If a maintainer confirms the shared-executor reading, I am happy to take it — either giving this test its own executor, or making the scheduler robust to a terminated pool. I would rather hear which of those you consider correct before writing it, since one is a test change and the other touches `CoordinatorService`. ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
