module: compile cache leaks temporary files when persistence fails

Version

v24.15.0

Platform

Linux pike 7.0.0-29-generic #29-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:52:35 UTC 2026 x86_64 GNU/Linux

Subsystem

module compile cache

What steps will reproduce the bug?

This uses RLIMIT_FSIZE=0 to make mkstemp() succeed and the subsequent write fail. It requires no third-party dependencies or elevated privileges.

tmp="$(mktemp -d)"
mkdir -p "$tmp/cache"
printf '%s\n' 'module.exports = 42;' >"$tmp/fixture.cjs"

(
  cd "$tmp"
  ulimit -f 0
  trap '' XFSZ
  NODE_COMPILE_CACHE="$tmp/cache" node -e "require('./fixture.cjs')"
)

find "$tmp/cache" -type f -printf '%P %s bytes\n'

Example output:

v24.15.0-x64-cf738c9d-1000/712488c2.LuhsmB 0 bytes
v24.15.0-x64-cf738c9d-1000/8e9c99c2.hwlSas 0 bytes
v24.15.0-x64-cf738c9d-1000/9fb526e9.wPP9zO 0 bytes

The Node process exits with status 0.

How often does it reproduce? Is there a required condition?

Every run on the Linux system above. The required condition is that creation of the temporary cache file succeeds but a later write, close, or rename fails. EDQUOT, ENOSPC, and EFBIG are representative failure modes.

What is the expected behavior? Why is that the expected behavior?

The compile cache should continue to fail gracefully, but it should close the temporary file descriptor and unlink the temporary file whenever persistence does not complete. A failed cache write is disposable internal state and should not consume additional filesystem space or inodes.

What do you see instead?

Each failed entry leaves its random-suffix temporary file in the compile-cache directory. On the write-error path, its file descriptor also remains open until process teardown.

In a real EDQUOT incident, one Node process left 3,424 zero-byte compile-cache temporary files in one minute. This amplified a block-quota failure into substantial inode consumption.

Additional information

Current main creates the temporary file, then immediately continues on write, close, or rename errors without unlinking it:

https://github.com/nodejs/node/blob/9d94b6548a8c3c18e5985ce2aef84b2bd8ea9ce0/src/compile_cache.cc#L478-L516

The same control flow is present in v24.15.0.

A possible fix is an RAII cleanup guard established immediately after successful uv_fs_mkstemp() that:

1. closes the descriptor if it is still open;
2. unlinks the temporary path unless the rename succeeded;
3. is disarmed only after successful rename;
4. preserves the original persistence error.

A regression test can use the same RLIMIT_FSIZE technique on supported POSIX platforms and assert that no random-suffix temporary files remain.

Inizia in src/compile_cache.cc intorno alle righe 478-516 ed esegui la riproduzione fornita di RLIMIT_FSIZE per tracciare la gestione dei file temporanei attraverso i fallimenti di write, close e rename. Aggiungi un test di regressione sulle piattaforme POSIX supportate che verifichi che una persistenza fallita non lasci file temporanei con suffisso casuale. Il lavoro è completato quando le scritture della cache fallite chiudono i descrittori, rimuovono i percorsi temporanei e preservano il fallimento gestito della cache.