test(runtime): let the dispatch-IC generation retry actually fire (#7365) - #7822
Conversation
|
Warning Review limit reached
Next review available in: 7 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
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 |
6ef3237 to
e6069be
Compare
Covers the 32 PRs admin-merged in one pass (audited in principle at the maintainer's direction): PerryTS#7768 PerryTS#7772 PerryTS#7779 PerryTS#7784 PerryTS#7785 PerryTS#7786 PerryTS#7788 PerryTS#7789 PerryTS#7797 PerryTS#7798 PerryTS#7801 PerryTS#7802 PerryTS#7804 PerryTS#7805 PerryTS#7806 PerryTS#7807 PerryTS#7808 PerryTS#7810 PerryTS#7811 PerryTS#7815 PerryTS#7816 PerryTS#7818 PerryTS#7819 PerryTS#7820 PerryTS#7821 PerryTS#7822 PerryTS#7823 PerryTS#7824 PerryTS#7825 PerryTS#7826 PerryTS#7827 PerryTS#7828. (PerryTS#7787 closed as already-landed via the PerryTS#7786 stack.) Per-change history lives in each PR's changelog.d fragment as usual. Claude-Session: https://claude.ai/code/session_01Y1QZ5wUP9gRSwpiweT4Wix
One of #7365's two named flaky tests is fixed:
obj_dispatch_ic_testsgoes from 10 of 12 isolated runs failing to 0 of 20.with_stable_genexists because dispatch-IC entries are keyed onVTABLE_GEN, and any class registration anywhere retires the cache — includinga_class_registration_invalidates_every_entryin the same module, which callstest_bump_vtable_generation()on purpose. So an insert/lookup pair can straddle a bump and miss for a reason that has nothing to do with what is being asserted. The helper was written to retry in exactly that case.The retry could never fire.
bodyasserted internally, so a straddled pair panicked on the setup assertion ("the entry we just inserted must be findable") before the loop got to re-check the generation. The 64-retry budget was never spent.bodynow returns whether its observations were valid:falsemeans "a bump landed mid-pair, nothing was learned", which is a retry rather than a failure. The assertions the tests exist for — a different name at the same address must miss, a different class id must miss, an over-long name must not alias a truncated key, a prefix must not hit — stay assertions.Why this matters beyond one test, and why it looked so strange. The failure rate inverted with scope: running only this module put its five tests — including the deliberate bumper — on threads together and failed 10 of 12, while the full 2000-test suite spread them apart and failed about 1 in 6. So the standard triage move, re-running just the failing test, made an intermittent test look reliably broken, and running the suite made it look nearly fine. Both readings were wrong, and #7365 is largely a catalogue of exactly that confusion.
Measured after the fix: 0/20 isolated runs fail. The full suite still fails about 1 in 10, but on a different test —
gc::tests::root_words::bare_address_in_global_root_survives_a_real_collection, a sibling of thebare_address_in_shadow_slot_…case already measured at 2/10 on cleanmain. That family is untouched here and remains #7365's other half; it is a GC-timing intermittency rather than a test-isolation one, so it needs a different fix.