lihaosky opened a new pull request, #28401:
URL: https://github.com/apache/flink/pull/28401

   ## What is the purpose of the change
   
   Backport of #28400 to `release-2.3` (clean cherry-pick of 
61723a08db52600363c89905913ce493a4f35d83).
   
   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. 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).
   
   ## 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]

Reply via email to