Skip to content

Give the real-git test its own vitest project, and archive the docs change - #193

Merged
VeryComplexAndLongName merged 1 commit into
mainfrom
fix/core-git-subprocess-project
Sep 3, 2026
Merged

Give the real-git test its own vitest project, and archive the docs change#193
VeryComplexAndLongName merged 1 commit into
mainfrom
fix/core-git-subprocess-project

Conversation

@VeryComplexAndLongName

Copy link
Copy Markdown
Owner

git.push.test.ts spawns around eight real git processes. On Windows it fails intermittently — a 5000 ms timeout, or MSYS's 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 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:

result
isolated project, run 1 pass
isolated project, run 2 fail
isolated project, run 3 fail
full core suite, run 1 fail
full core suite, run 2 pass — 44 files, 516 tests, git.push.test.ts green in 1865 ms

The 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-documentation archived, complete.
  • The two task notes that had recorded these failures as "co-load timeout flakiness" under load-sensitive-test-timeouts are 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/core full suite — 44 files / 516 tests green (second run; see the table for the first)
  • Isolated project runs recorded above
  • npm run lint:english — passed
  • CI green

🤖 Generated with Claude Code

…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>
@VeryComplexAndLongName
VeryComplexAndLongName merged commit e47ac25 into main Sep 3, 2026
7 checks passed
@VeryComplexAndLongName
VeryComplexAndLongName deleted the fix/core-git-subprocess-project branch September 3, 2026 07:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant