test: shrink the concurrency harness to the scale this tool is actually used at - #30
Merged
Merged
Conversation
…ly used at The shared-state concurrency block was a 12-writer storm against a planted stale lock with CPU pressure, spread over eight throwaway repos. It was built to prove the locking rewrite under hostile conditions, it did that, and then it cost 113 lines and roughly a third of the suite's runtime on every run afterwards. The realistic case is two or three parallel sessions. The block now runs three concurrent writers against the branch index and three pairs against CLAUDE.md, in 45 lines. What that trades away, stated plainly: with the lock neutered, the trimmed block still fails, but only on the CLAUDE.md duplicate-block assertion. Three writers is not enough to reproduce the lost index row that twelve reproduced reliably. So this is a weaker detector of the same bug, not an equivalent one. The lock implementation in bin/claude-team is unchanged, and the deterministic tests that cover it directly, liveness outranking the age rule and the takeover leaving no directory behind, are untouched. Runtime 16.8s to 12.1s. 269 tests to 258. tests/run.sh 1637 lines to 1569. I also tried shrinking the 8 MB fixture in the SIGINT test and reverted it: it saved nothing measurable, and a smaller file narrows the window the signal has to land in, which is the exact flake that failed on macOS earlier. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019j5DHEZsoeCGRueTbNLuTb
d6veteran
marked this pull request as ready for review
July 30, 2026 22:18
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
2 participants
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.
Tests only. No code touched.
The concurrency block was a 12-writer storm against a planted stale lock with CPU pressure across eight throwaway repos. It was built to prove the locking rewrite under hostile conditions. It did that, then cost 113 lines and about a third of the suite's runtime on every run afterwards.
Realistic usage is two or three parallel sessions. Now three concurrent writers against the branch index and three pairs against
CLAUDE.md, in 45 lines.tests/run.shWhat this trades away
Stated plainly, because it is a real loss: with the lock neutered, the trimmed block still fails, but only on the
CLAUDE.mdduplicate-block assertion. Three writers is not enough to reproduce the lost index row that twelve reproduced reliably.So this is a weaker detector of the same bug, not an equivalent one. Verified by disabling
lock_acquireand running it.The lock implementation is unchanged, and the deterministic tests covering it directly are untouched: liveness outranking the age rule, an ancient lock held by a live PID not being broken, and the takeover leaving no directory behind.
One thing I tried and reverted
Shrinking the 8 MB fixture in the SIGINT test. It saved nothing measurable (11.6s vs 11.7s, noise), and a smaller file narrows the window the signal has to land in — the exact flake that failed on macOS earlier today. Reverted.
Scope honesty
I estimated ~240 lines out. Actual is 68. The other blocks I flagged as candidates turned out to be deterministic and fast, so cutting them would have removed coverage for no runtime gain.
Generated by Claude Code