ix-cli/src/cli/__tests__/watch-dedup.test.ts:99.
What was seen
Five failures on 2026-09-01, all of canonical watch refresh > starts both the tsx source CLI and a normal built CLI child:
- once inside a full
vitest run (1 failed / 1508 passed)
- then four consecutive times running that file alone, in the same worktree, against clean
main (793c56b) with local changes stashed
What could not be reproduced
In a fresh worktree at the same commit, the test passed 15/15 on every attempt — roughly twelve runs, including six while a full vitest run was executing concurrently to load the machine.
I could not capture the assertion message before the failing worktree was removed, which is the main gap here. If anyone hits this, please paste the failure output — the two expect(status, stderr) assertions carry the child's stderr and would name the cause immediately.
Hypotheses tested and ruled out
| hypothesis |
result |
| Disk pressure (machine was at 97%, 1.6G free) |
No. The build the test performs is only 1.3M / 89 files. |
Leftover .watch-child-runtime-* debris from an earlier interrupted run |
No. Recreated the debris (including a full dist inside it) and the test still passed 15/15. |
The update notice leaking onto stdout and breaking the --version assertion |
No. With a fresh IX_HOME seeded exactly as the test seeds it, stdout is exactly 0.10.5 and nothing else. |
Why this test is more exposed than most
The test body does real work in the environment rather than asserting on pure functions like the rest of the file:
- spawns
src/cli/main.ts under tsx and asserts --version on stdout
- shells out to a full
tsc -p tsconfig.build.json build and asserts build.status === 0 (:130-143)
- spawns the built CLI and asserts on
--help
Any environmental problem in step 2 or 3 fails the test for a reason unrelated to what it is checking, which is whether the child process starts.
A separate, definite defect worth fixing either way
:109 creates its temp dir inside the package root:
const tempRoot = fs.mkdtempSync(path.join(packageRoot, ".watch-child-runtime-"));
Cleanup is in a finally, which does not run if the process is killed. An interrupted run therefore leaves a complete dist build sitting in the working tree — I hit exactly this and found .watch-child-runtime-ZLHEp7/ as an untracked directory afterwards. It is also not in .gitignore, so it shows up in git status and can be committed by accident.
Moving tempRoot to the OS tmpdir fixes both, and costs nothing — nothing in the test requires it to be under packageRoot (packageRoot is already passed explicitly as cwd to each spawnSync).
Found while verifying #566; not caused by it.
ix-cli/src/cli/__tests__/watch-dedup.test.ts:99.What was seen
Five failures on 2026-09-01, all of
canonical watch refresh > starts both the tsx source CLI and a normal built CLI child:vitest run(1 failed / 1508 passed)main(793c56b) with local changes stashedWhat could not be reproduced
In a fresh worktree at the same commit, the test passed 15/15 on every attempt — roughly twelve runs, including six while a full
vitest runwas executing concurrently to load the machine.I could not capture the assertion message before the failing worktree was removed, which is the main gap here. If anyone hits this, please paste the failure output — the two
expect(status, stderr)assertions carry the child's stderr and would name the cause immediately.Hypotheses tested and ruled out
.watch-child-runtime-*debris from an earlier interrupted rundistinside it) and the test still passed 15/15.--versionassertionIX_HOMEseeded exactly as the test seeds it, stdout is exactly0.10.5and nothing else.Why this test is more exposed than most
The test body does real work in the environment rather than asserting on pure functions like the rest of the file:
src/cli/main.tsunder tsx and asserts--versionon stdouttsc -p tsconfig.build.jsonbuild and assertsbuild.status === 0(:130-143)--helpAny environmental problem in step 2 or 3 fails the test for a reason unrelated to what it is checking, which is whether the child process starts.
A separate, definite defect worth fixing either way
:109creates its temp dir inside the package root:Cleanup is in a
finally, which does not run if the process is killed. An interrupted run therefore leaves a completedistbuild sitting in the working tree — I hit exactly this and found.watch-child-runtime-ZLHEp7/as an untracked directory afterwards. It is also not in.gitignore, so it shows up ingit statusand can be committed by accident.Moving
tempRootto the OS tmpdir fixes both, and costs nothing — nothing in the test requires it to be underpackageRoot(packageRootis already passed explicitly ascwdto eachspawnSync).Found while verifying #566; not caused by it.