test: deflake retry jitter test under coverage instrumentation#232
Conversation
test_with_retry_repeated_retry_after_zero_sleeps_before_each_retry advanced the paused clock and then relied on a single yield_now for the spawned retry task to cross the fired-timer boundary before asserting the attempt count. Under llvm-cov's slower, perturbed scheduling one yield is not always enough, so the count lagged (left: 1, right: 2) and the Coverage CI job flaked. Replace the single yield before each positive count assertion with a bounded wait_for_attempt_count() poll loop that yields until the expected count is observed (capped to avoid hangs). The negative 'must not retry before the floor' assertions keep the single yield — the 100ms floor makes early firing impossible, so they are deterministic. Timing behavior verified unchanged: 25/25 passes under cargo llvm-cov. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 9 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Ready to review this PR? Stage has broken it down into 2 individual chapters for you:
Chapters generated by Stage for commit 9928c79 on Jul 5, 2026 1:03pm UTC. |
✅ Code Coverage Report
View detailed coverageDownload the Or run locally: cargo llvm-cov --html
open target/llvm-cov/html/index.html |
The wait_for_attempt_count helper's iteration-cap panic branch was never exercised by passing tests, leaving one uncovered line that tripped the fail-on-any-decrease coverage gate. Add a should_panic test that drives the helper with a count that never arrives, covering the timeout diagnostic. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
1 participant
The Coverage CI job (llvm-cov) intermittently failed
push::retry::tests::test_with_retry_repeated_retry_after_zero_sleeps_before_each_retrywithassertion left == right failed, left: 1, right: 2.Root cause: the test advances tokio's paused clock and then relied on a single
tokio::task::yield_now().awaitfor the spawned retry task to cross the fired-timer boundary before asserting the attempt count. Under llvm-cov's slower, perturbed scheduling one yield is not always enough, so the count lagged. The standardTestjob passes; only the instrumentedCoveragejob tripped.Fix: replace the single yield before each positive count assertion with a bounded
wait_for_attempt_count()helper that yields until the expected count is observed (capped at 10k iterations to avoid hangs). The retry task runs from 'sleep fires' → increment → re-park in a single poll with no intervening await, so observing the incremented count cannot race ahead of the task re-parking — the sleep-deadline timing is unchanged. The negative 'must not retry before the 100ms floor' assertions keep the single yield: the floor makes early firing impossible, so they are already deterministic. No timing assertion is weakened.Verified: 25/25 passes under
cargo llvm-cov(the exact instrumentation CI uses), plus 40/40 plain.🤖 Generated with Claude Code