test: stabilize flaky resource manager client tests#11011
Conversation
Wait for standalone resource manager metadata and RU statistics to become observable before asserting their values. Measure token bucket wait time using the duration returned by the controller so host scheduling delays do not make timing assertions flaky. Signed-off-by: Ryan Leung <rleungx@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughIntegration tests now account for asynchronous resource-group propagation by polling for visibility, controller state, RU statistics, and fill-rate updates. Controller timing assertions use durations returned by request handling instead of measuring elapsed wall-clock time. ChangesResource manager integration test stability
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What problem does this PR solve?
Issue Number: Close #10650, Close #8512, Close #8739, Close #7400, Ref #6810
Several tests in TestResourceManagerClientTestSuite assume that asynchronous
resource-manager state is visible immediately or include unrelated wall-clock
overhead in timing assertions. These assumptions make the suite flaky under CI
load, especially with standalone resource-manager discovery.
What is changed and how does it work?
The existing final assertions remain in place. The changes only replace
immediate reads and fixed sleeps with condition-based waits and use the
controller-reported wait duration for the timing check.
Check List
Tests
Release note
Summary by CodeRabbit