MartijnVisser opened a new pull request, #28645: URL: https://github.com/apache/flink/pull/28645
## What is the purpose of the change `RescaleTimelineITCase.testRecordNonTerminatedRescaleMergingWithNewRecoverableFailureTriggerCause` is flaky (Azure nightly build [76751](https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=76751&view=results), leg `test_cron_adaptive_scheduler core`): it fails with `expected: RECOVERABLE_FAILOVER but was: UPDATE_REQUIREMENT`. After killing a TaskManager to trigger a recoverable failover, the test waited via `waitForVertexParallelismReachedAndJobRunning(..., PARALLELISM)`. Because `waitUntilCondition` checks its predicate before sleeping, that condition is satisfied immediately by the stale pre-failover state (the job is still observed RUNNING at `PARALLELISM`), so the wait does not synchronize with the failover at all. After the failover the job returns at a lower parallelism (a TaskManager is gone), so `PARALLELISM` is never seen again, confirming the wait can only match the stale state. The `ExecutionGraphInfo` snapshot could therefore be taken before the scheduler merged the failover into the in-progress `UPDATE_REQUIREMENT` rescale and re-stamped its trigger cause, so the test observed `UPDATE_REQUIREMENT`. This is a test-only race; the scheduler behavior is correct. Distinct from the earlier races fixed in this class (FLINK-39902, FLINK-39903, FLINK-40009, FLINK-40010) and from FLINK-40067 (#28633), which all target other methods. ## Brief change log - Replace the ineffective parallelism/running wait after the TaskManager termination with a wait until the recoverable failover has been merged into the in-progress rescale (history size 2, latest trigger cause `RECOVERABLE_FAILOVER`), guarded on the enabled-history parameter (the disabled-history leg records nothing and still asserts an empty history, so it needs no wait). - The assertion is unchanged; only the synchronization before snapshotting is corrected. ## Verifying this change This change is already covered by the existing test `RescaleTimelineITCase#testRecordNonTerminatedRescaleMergingWithNewRecoverableFailureTriggerCause`. Verified by running it 25 times (50 executions across both parameterizations); all green. `spotless:check` passes. ## 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? - [X] Yes (please specify the tool below) Generated-by: Claude Opus 4.8 (via Claude Code) -- 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]
