MartijnVisser opened a new pull request, #28633:
URL: https://github.com/apache/flink/pull/28633
## What is the purpose of the change
Fixes a test-side timing race that makes
`RescaleTimelineITCase.testRescaleTerminatedByJobFinished` flaky on loaded CI
machines (Azure build 76571, leg `test_cron_hadoop313_core`). With the short
100ms cooldown shared by the parameterized fixture, the cooldown-driven
`Idling` transition of `DefaultStateTransitionManager` terminates the
in-progress rescale with `NO_RESOURCES_OR_PARALLELISMS_CHANGE` before the job
finishes; `goToFinished`'s later `JOB_FINISHED` stamp is then dropped
(`DefaultRescaleTimeline#updateRescale` is a no-op once the rescale is
terminated), so the awaited condition can never be met. The timeout only became
observable after FLINK-40009 made the wait helper's budget real. Both terminal
reasons are legitimate product behaviour; this is not a product bug.
## Brief change log
- Skip the disabled-history parameter up front so it does not pay for a
cluster rebuild.
- Rebuild the fixture cluster with a 60s executing cooldown/stabilization
via the existing `rebuildClusterWithExecutingTimeouts` helper, keeping the
in-progress rescale alive past the unblock-to-finish window (mirrors the
sibling fixes FLINK-39903/FLINK-40010).
- Widen the final wait budget for headroom on loaded CI legs.
## Verifying this change
This change is already covered by existing tests. Ran
`testRescaleTerminatedByJobFinished` 4x and the full `RescaleTimelineITCase`
(30 run, 0 failures, 8 skipped); the method now completes in under 2 seconds,
confirming `JOB_FINISHED` is stamped while the rescale is still in progress
rather than waiting out any timer. The original failure needs a starved
JobManager thread on a loaded CI machine and is not reproducible locally; the
fix removes the dependency on that timer ordering entirely.
## 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
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (Claude Opus 4.8, via Claude Code)
Generated-by: Claude Opus 4.8 (1M context)
--
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]
