NickM83
### Version v24.18.0 ### Platform Microsoft Windows 11 Pro 10.0.26200, x64. `LongPathsEnabled` = 1. ### Subsystem module (compile cache) ### What steps will reproduce the bug? Run this PowerShell script. It calls `module.enableCompileCache()` on directories of different lengths under `%TEMP%`, and kills any call that has not returned after 6 seconds. ```powershell $base = Join-Path $env:TEMP 'cc-repro' New-Item -ItemType Directory -Force -Path $base | Out-Null foreach ($len in 200, 220, 230, 240, 245, 250, 260, 300) { $p = $base; $i = 0 while ($p.Length -lt $len) { $p = Join-Path $p ("d" + ($i++)) } $p = $p.Substring(0, $len).TrimEnd('\') $psi = [System.Diagnostics.ProcessStartInfo]::new('node.exe') $psi.Arguments = "-e `"const r=require('module').enableCompileCache(process.argv[1]);console.log(r.status+' '+(r.message||''))`" `"$p`"" $psi.UseShellExecute = $false; $psi.RedirectStandardOutput = $true $proc = [System.Diagnostics.Process]::Start($psi) if (-not $proc.WaitForExit(6000)) { $proc.Kill(); "{0} chars: HANG" -f $p.Length } else { "{0} chars: {1}" -f $p.Length, $proc.StandardOutput.ReadToEnd().Trim() } } ``` ### How often does it reproduce? Is there a required condition? It happens every time for directory lengths 240 and 245, with `%TEMP%` under `C:\Users\<user>\AppData\Local\Temp`. The exact lengths that hang depend on the path's structure. In our case a real 283-character cache path also hung, while the synthetic 282-character path above fails cleanly. ### What is the expected behavior? Why is that the expected behavior? `enableCompileCache()` should return. It should either enable the cache or report failure, as it does for every other length: ``` 200 chars: 1 220 chars: 1 230 chars: 0 Cannot create cache directory: no such file or directory 234 chars: 0 Cannot create cache directory: no such file or directory 240 chars: HANG 245 chars: HANG 250 chars: 0 Cannot create cache directory: no such file or directory 260 chars: 0 Cannot create cache directory: no such file or directory 300 chars: 0 Cannot create cache directory: no such file or directory ``` ### What do you see instead? The call never returns. The main thread spins inside native code: - One core runs at 100%. - Process I/O counters show about 150,000 file-system metadata operations a second (`OtherOperationCount`), with no writes. - Timers never fire, and the inspector cannot pause the thread, so neither `--cpu-prof` nor `Debugger.pause` produces a stack. - A `--prof` tick profile attributes about 99% of ticks to `ntdll.dll` under the calling script. The same hang occurs when the cache is enabled through the `NODE_COMPILE_CACHE` environment variable. In a worker thread, that variable also freezes a main thread that is waiting on the worker. ### Additional information We hit this in production: an application enabled the compile cache in its launcher, its entry module and its worker threads, using a cache path built from a long build ID. A maintenance command then spun for 25 minutes before it was killed. Workaround: `NODE_DISABLE_COMPILE_CACHE=1`. `fs.mkdirSync(path, { recursive: true })` succeeds for all of these lengths on the same machine, so the problem appears specific to the compile-cache directory creation path. It may be an `MKDirp` retry loop on ENOENT for paths near `MAX_PATH` without the `\\?\` prefix.