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.

Start in src/compile_cache.cc around lines 478-516 and run the provided RLIMIT_FSIZE reproduction to trace temporary-file handling through write, close, and rename failures. Add a regression test on supported POSIX platforms that verifies failed persistence leaves no random-suffix temporary files. Done means failed cache writes close descriptors, remove temporary paths, and preserve graceful cache failure.