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.

Commencez dans src/compile_cache.cc autour des lignes 478-516 et exécutez la reproduction RLIMIT_FSIZE fournie afin de suivre la gestion des fichiers temporaires lors des échecs de write, close et rename. Ajoutez un test de régression sur les plateformes POSIX prises en charge qui vérifie qu’une persistance échouée ne laisse aucun fichier temporaire à suffixe aléatoire. C’est terminé lorsque les écritures de cache échouées ferment les descripteurs, suppriment les chemins temporaires et préservent l’échec contrôlé du cache.