Module tmp-copy write failure is swallowed, later fetches point to a never-written file (ENOENT in workers when TMPDIR volume is nearly full)

[Mondragondon]

Describe the bug

When the volume holding os.tmpdir() runs out of space after the per-project tmp directory was created, writing the module tmp copy fails. The failure is only logged via debugFs, but the module is still marked as cached (transformResult.__vitestTmp = tmpFile). Subsequent fetches of the same module then return a result pointing to that file, which was never written, and the worker fails with:

Error: ENOENT: no such file or directory, open '<TMPDIR>/<id>/ssr/<sha1>'

The real cause (ENOSPC) is invisible in the output, so the failure looks like a random missing-file flake.

Where (vitest 5.0.3, dist/chunks/index.DpLw24bj.js)

• cacheResult() (~line 6495): .catch(...) only calls debugFs$1?.("failed to cache ...") and returns result.
• Caller in the cachePath == null / makeTmpCopies branch (~lines 6312-6322): .then(() => { if (transformResult) transformResult.__vitestTmp = tmpFile; ... }) runs also after a failed write.
• Next fetch (~line 6313): if (typeof tmpPath === "string") return getCachedResult(result, tmpPath) returns the path of the missing file.

5.0.3 already serves the first result inline after a failed write, but the __vitestTmp marker is still set, so the second fetch of that module breaks. Same behaviour in 5.0.1.

Reproduction

Minimal project: src/a.ts (export const a = () => 1), src/b.ts (imports a), three test files importing b. Run on macOS with a 3 MB HFS+ disk image mounted as TMPDIR, filled so only a few KB remain:

hdiutil create -size 3m -fs HFS+ -volname SMALLTMP small.dmg
hdiutil attach small.dmg -nobrowse
mkfile -n <free-8>k /Volumes/SMALLTMP/fill     # leave ~8 KB free
TMPDIR=/Volumes/SMALLTMP npx vitest run

Result with 8 KB left: Test Files 2 failed | 1 passed (3) on 5.0.1, 1 failed | 2 passed (3) on 5.0.3, with ENOENT ... /ssr/<sha1>. With 12 KB or more left the run passes; with 0 KB left mkdir fails with a clear ENOSPC.

Expected

• Do not set __vitestTmp when the write failed (or verify the file exists before returning getCachedResult), and keep serving the module inline.
• Surface the underlying ENOSPC/EIO error instead of only a debug log.

Environment

vitest 5.0.1 / 5.0.3, Node v25.4.0, macOS arm64 (observed originally on a Linux CI runner with a nearly full root volume).

[RandyNorthrup]

More evidence for this one: a second trigger, and a reproduction that doesn't need a tiny volume.

Second trigger: a per-user quota (EDQUOT) under parallel load. We hit this on Linux, where /tmp is a tmpfs with a per-user quota (systemd tmp.mount with usrquota). The volume was not full; the user's quota was. Under parallel test load the tmp-copy writes failed with EDQUOT. Test files then failed before any test body ran, with ENOENT: no such file or directory, open '/tmp/<id>/ssr/<sha1>'. So any failed write (quota, ENOSPC, EPERM) triggers it, not only a nearly full disk.

What used up the quota was leftover /tmp/<id>/ssr directories, about 1,500 of them (3 GiB) on one machine. They came from 5.0.2's root Vitest._tmpDir, which is never removed (#11224, fixed in 5.0.3 by #11248). That fix stops the leak on a clean exit. A killed run never reaches close(), though, and still leaves its directory behind, so the condition can come back.

Reproduction on Windows 11, same result on 5.0.2 and 5.0.3. Deny "add file" on a throwaway TEMP directory, inherited by subfolders only. Creating folders still works, so vitest creates <id>\ssr, but every tmp-copy write then fails with EPERM:

mkdir C:\repro\app\src, C:\repro\tmp; cd C:\repro\app
'{"private":true,"type":"module"}' | Set-Content package.json
npm i -D vitest@5.0.3
'export const value = 42' | Set-Content src\shared.js
foreach ($n in 'a','b','c') {
  "import { value } from './src/shared.js'`ntest('$n', () => { expect(value).toBe(42) })" | Set-Content "$n.test.js"
}
icacls C:\repro\tmp /deny "${env:USERNAME}:(CI)(WD)"   # WD = add file, (CI) = inherited by folders only
$env:TEMP = 'C:\repro\tmp'; $env:TMP = 'C:\repro\tmp'
node node_modules/vitest/vitest.mjs run --globals --no-file-parallelism
# cleanup: icacls C:\repro\tmp /remove:d $env:USERNAME

Every run fails the same way (5 of 5 on 5.0.2, 8 of 8 on 5.0.3). The first file passes and every later file that imports src/shared.js fails:

 FAIL  b.test.js [ b.test.js ]
Error: ENOENT: no such file or directory, open 'C:\repro\tmp\<id>\ssr\<sha1>'
 ❯ b.test.js:1:1
 Test Files  2 failed | 1 passed (3)

The same steps with a writable TEMP pass. Without --no-file-parallelism the result depends on timing (it failed in 2 of 5 runs on 5.0.2). Concurrent first fetches share the in-flight saveCachePromises entry and get the inline result. Only a fetch that arrives after the .then has set the marker gets the missing path. The real error shows up only with DEBUG=vitest:cache:fs:

vitest:cache:fs failed to cache …/ssr/<sha1>, serving it inline: Error: EPERM: operation not permitted, open '…\ssr\.tmp-…'

Where it happens. Line numbers are from 5.0.2's dist/chunks/index.C-uw7tH9.js. The same code is unchanged on main in packages/vitest/src/node/environments/transformService.ts (L171-190, L503-530).

• In ModuleFetcher.fetch (L6320-6322), this.cacheResult(...).then(() => { transformResult.__vitestTmp = tmpFile }) always runs. It runs both when cacheResult resolves to the cached result and when it resolves to the inline fallback from its .catch (L6474-6476).
• On the next fetch (L6312-6313), getCachedResult(result, tmpPath) is returned without an existsSync check. getCachedModule (L6390-6395) does have one and re-transforms when the file is gone; this branch doesn't.
• In the worker (dist/chunks/index.hTNFpC24.js), the warm-snapshot read (L789-794) is wrapped in try {} catch {} and falls back to RPC. The RPC result at L799-802 is read with readFileSync(result.tmp, "utf-8") and has no fallback; that is where the ENOENT is thrown. fetchWarmModules (index.C-uw7tH9.js L10498) passes the missing path on to workers as well.

The change in #11462 (auto-closed and moved to #11481) fixes the first point: it records __vitestTmp only when cacheResult returned the cached result. Adding an existsSync guard before getCachedResult, or an inline re-fetch on ENOENT in the worker, would make this recover on its own. Showing the swallowed write error as a warning, not only under DEBUG, would also make the cause visible.

Environment for the Windows reproduction: Node 24.20.0, Windows 11 Pro 10.0.26200.