lihaosky opened a new pull request, #28400: URL: https://github.com/apache/flink/pull/28400
## What is the purpose of the change Fixes the failure mode behind [FLINK-37892](https://issues.apache.org/jira/browse/FLINK-37892) (`SplitFetcherManagerTest#testCloseBlockingWaitingForFetcherShutdown` flaking on CI). `TestUtils#waitUntil` evaluates the condition twice — once in the polling loop and again to decide whether to throw: ```java while (!condition.get() && System.currentTimeMillis() < startTime + timeout.toMillis()) { Thread.sleep(1); } if (!condition.get()) { throw new TimeoutException(message); } ``` A non-monotonic condition that is momentarily true and then false again can exit the loop on the first evaluation and fail the second, producing a `TimeoutException` within milliseconds despite a 30s budget. `SplitFetcherManagerTest` passes exactly such a condition (`findThread(THREAD_NAME_PREFIX).size() == 2` — a live thread count that can flicker as fetcher threads start/exit). The recent nightly failures confirm this mechanically: the test "timed out" after **0.027s / 0.039s** against a 30-second budget ([run 27320852550](https://github.com/apache/flink/actions/runs/27320852550), original + re-run, two different profiles) — impossible for a real timeout, and exactly the signature of the double-evaluation race. ## Brief change log - Restructure `TestUtils#waitUntil(Supplier, Duration, String)` to evaluate the condition once per iteration and latch the result: a condition observed as true always completes the wait; `TimeoutException` is thrown only when the condition was actually false at the deadline. - Add `TestUtilsTest` with a regression test whose condition is satisfied exactly once and false afterwards. ## Verifying this change This change added tests and can be verified as follows: - `TestUtilsTest#testWaitUntilSucceedsForConditionSatisfiedOnlyOnce` fails against the old implementation with the same spurious `TimeoutException` (in ~0.04s) and passes with the fix. - `SplitFetcherManagerTest` passes against the fixed utility. ## Does this pull request potentially affect one of the following parts: - Dependencies (does it add or upgrade a dependency): no - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: no - The serializers: no - The runtime per-record code paths (performance sensitive): no - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no - The S3 file system connector: no ## Documentation - Does this pull request introduce a new feature? no - If yes, how is the feature documented? not applicable --- ##### Was generative AI tooling used to co-author this PR? Yes -- 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]
