Skip to content

split invalidate_randomly into two deterministic tests#23280

Draft
cburroughs wants to merge 1 commit intopantsbuild:mainfrom
cburroughs:csb/flake-10839
Draft

split invalidate_randomly into two deterministic tests#23280
cburroughs wants to merge 1 commit intopantsbuild:mainfrom
cburroughs:csb/flake-10839

Conversation

@cburroughs
Copy link
Copy Markdown
Contributor

This test was identified as flaky in 2020 and went through a prior re-enable/backout dance. On my workstation with no load I can run it 1000 times without error. Under artificial cpu load (nice + dummy procs) it fails ~20% of the time. So I think this is a straightforward timing based assertion problem.

To "fix" this, the test is broken out into two smaller tests:

  • An assertion on small deterministic inputs.
  • Liveness under random invalidation.

I think the ideal fix would be some sort of fuzz or property based testing system. But since we one hasn't been adopted already and this test has hung out for six years, I think this is a positive incremental move forward.

closes #10839

Notice: A LLM both did the "run the tests a bunch scripting" and geneated the final code. I made the call on splitting versus futzing with timeouts or high scope logical clock changes.

This test was identified as flaky in 2020 and went through a prior
re-enable/backout dance.  On my workstation with no load I can run it
1000 times without error.  Under artificial cpu load (nice + dummy
procs) it fails ~20% of the time.  So I think this is a
straightforward timing based assertion problem.

To "fix" this, the test is broken out into two smaller tests:
 * An assertion on small deterministic inputs.
 * Liveness under random invalidation.

I think the ideal fix would be some sort of fuzz or property based
testing system.  But since we one hasn't been adopted already and this
test has hung out for six years, I think this is a positive
incremental move forward.

closes pantsbuild#10839

Notice: A LLM both did the "run the tests a bunch scripting" and
geneated the final code.  I made the call on splitting versus futzing
with timeouts or high scope logical clock changes.
@cburroughs cburroughs self-assigned this Apr 21, 2026
@cburroughs cburroughs added the release-notes:not-required [CI] PR doesn't require mention in release notes label Apr 21, 2026
@cburroughs
Copy link
Copy Markdown
Contributor Author

@jsanders would you mind taking a look at this rust code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release-notes:not-required [CI] PR doesn't require mention in release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Rust invalidate_randomly test is flaky

1 participant