The GitHub Actions job "Flink CI (beta)" on flink.git/release-2.3 has failed. Run started by GitHub user lihaosky (triggered by lihaosky).
Head commit for run: 2124a2c0b60dda3cb87d4d4ea29c873ece7b0c29 / Yuepeng Pan <[email protected]> [FLINK-39903][tests] Fix race in RescaleTimelineITCase.testRescaleTerminatedByResourceRequirementsUpdated (#28379) (#28414) The test issues two sequential updateJobResourceRequirements RPCs and asserts that the in-progress rescale started by the first update is terminated by the second update with terminal reason RESOURCE_REQUIREMENTS_UPDATED. For that to hold, the second update must be processed while the first rescale is still in-progress. AdaptiveScheduler#recordRescaleForNewResourceRequirements sets RESOURCE_REQUIREMENTS_UPDATED via RescaleTimeline#updateRescale, which is a no-op once the current rescale is already terminated (DefaultRescaleTimeline#isIdling). With the short cooldown (100 ms) and resource-stabilization (50 ms) timeouts that the parameterized configuration shares with the other cases, the DefaultStateTransitionManager re-enters its Idling phase and the Idling constructor terminates the in-progress rescale with NO_RESOURCES_OR_PARALLELISMS_CHANGE (the upper bound exceeds the available slots, so no parallelism change is possible). On a slow machine this happens before the second update RPC is processed, so the second update finds the rescale already terminated and its RESOURCE_REQUIREMENTS_UPDATED setter is ignored, producing the flaky assertion failure. This is a test-side timing assumption, not a product bug: re-entering Idling and recording NO_RESOURCES_OR_PARALLELISMS_CHANGE is the correct behavior for an in-progress rescale that cannot change parallelism. That termination is driven by wall-clock timers that start the moment the first rescale is recorded, so no amount of waiting between the two updates can guarantee the second update wins the race; waiting only consumes the same budget. Widening cooldown and stabilization for this case is therefore the only deterministic test-side fix: it keeps the in-progress rescale alive far longer than the single synchronous RPC round trip between the two updates. 60 s is an intentionally generous bound (the suite already uses second-scale guards for slow CI) and has no cost because the test completes as soon as the second update lands. To avoid running two clusters, rebuild the shared fixture cluster in place with the widened configuration instead of starting a dedicated one on top of the @BeforeEach cluster, so only one cluster is ever running and the @AfterEach teardown still applies. The disabled-history parameter is skipped up front, mirroring the sibling cases, so it does not pay for a cluster rebuild it never asserts on. The shared parameterized configuration relied upon by the other cases is left untouched. Generated-by: Claude Opus 4.8 (1M context) (cherry picked from commit aa52739877badaca3f9afd6efbec975c66476197) Co-authored-by: Martijn Visser <[email protected]> Report URL: https://github.com/apache/flink/actions/runs/27474046642 With regards, GitHub Actions via GitBox
