Give the real-git test its own vitest project, and archive the docs change - #193
Merged
Merged
Conversation
…hange git.push.test.ts spawns around eight real git processes. On Windows it fails intermittently with either a 5000 ms timeout or an MSYS add_item ... errno 1, and the investigation recorded in core-test-worker-contention traces that to Git for Windows' fork-emulation racing when its subprocesses run concurrently with other git subprocesses. The file now runs in its own single-fork vitest project instead of sharing a worker with the other 43 files in the package, and instead of forcing all of them onto a single fork, which was tried and rejected for slowing every other file to fix one. I checked this by trying to refute it. My hypothesis was that splitting into two projects changes nothing, because vitest runs projects concurrently - so the isolated file would still race the other 43. The evidence says otherwise, and says my hypothesis was wrong: the isolated project alone passed, then failed twice in a row; the full core suite failed once and then passed 44 files and 516 tests with git.push.test.ts green in 1865 ms. The failure appears in both configurations and in neither reliably. That is exactly what the change's own honesty note under task 4.3 says - a residual rate that no vitest configuration controls, on an environment its operating instructions describe as not a dedicated machine. The note is right, and I nearly reported a correction the evidence does not support. Recording that here because the only reason I did not is that I repeated the runs. Also archives agentic-harness-documentation, complete, and corrects the two task notes that had recorded these failures as co-load timeout flakiness under load-sensitive-test-timeouts. Those notes are inside archived changes: the corrections name the earlier workaround and what it actually was, rather than silently reading as if they had always said so, which keeps the archive a record rather than a rewrite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
git.push.test.tsspawns around eight realgitprocesses. On Windows it fails intermittently — a 5000 ms timeout, or MSYS'sadd_item ... errno 1— and the investigation recorded incore-test-worker-contentiontraces that to Git for Windows' fork-emulation racing when its subprocesses run concurrently with other git subprocesses.The file now runs in its own single-fork vitest project rather than sharing a worker with the other 43 files in the package — and rather than forcing all of them onto a single fork, which was tried and rejected for slowing every other file to fix one.
I tried to refute it, and failed
My hypothesis: splitting into two projects changes nothing, because vitest runs projects concurrently — so the isolated file would still race the other 43. First two observations seemed to confirm it (isolated: pass in 2.65 s; full suite: timeout).
Then I repeated the runs:
git.push.test.tsgreen in 1865 msThe failure appears in both configurations and in neither reliably. My hypothesis was wrong, and the change's own honesty note under task 4.3 was right: a residual rate that no vitest configuration controls, on an environment its operating instructions describe as not a dedicated machine.
Recording that here because I nearly reported a correction the evidence does not support, and the only reason I did not is that I repeated the runs.
Also in this PR
agentic-harness-documentationarchived, complete.load-sensitive-test-timeoutsare corrected. Those notes live inside archived changes; the corrections name the earlier workaround and what it actually was, rather than silently reading as though they had always said so — which keeps the archive a record rather than a rewrite.Test plan
packages/corefull suite — 44 files / 516 tests green (second run; see the table for the first)npm run lint:english— passed🤖 Generated with Claude Code