Repository navigation
Conversation
…I flake) ticks_only_while_active gave the ticker thread a fixed 30 ms after touch() to land a read; on loaded CI runners it failed intermittently at the "touched: ticking" assert (four PRs on 2026-10-18, none touching spark-storage). Keep touching until a read lands (5 s bound), then stop and require the count to hold still across 200 ms (5x the idle window, 5 s bound). Same properties, no scheduling race. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ngram_cache::keepalive::tests::ticks_only_while_activefailed intermittently in CI'scargo test --workspaceon 2026-10-18 (#182 once, #183 twice, #186 once). None of those PRs touchspark-storage, and each re-run passed. It always failed at the same assert (keepalive.rs:201, "touched: ticking"): aftertouch()the test gave the 2 ms ticker a fixed 30 ms to land a read, inside a 40 ms idle window.Change: test only; no runtime code changes.
The test asserts the same three properties (no reads before a resolve, reads while touched, quiet after
idle) without racing the scheduler.On reproducing it: I could not reproduce the flake locally. The old test passed 100/100 on a 32-core Linux box with every core saturated, and 100/100 pinned to one CPU shared with six busy loops; the new test also passed 200/200 under both. So the CI failures most likely come from runner scheduling stalls (CPU steal, timer coarseness) that a dedicated box doesn't show. A filesystem fault is ruled out: a failed read stops the ticker permanently, which would fail every run, not intermittently.
🤖 Generated with Claude Code