AI & Agent Dev Bug Sandbox logo
AI & Agent Dev Bug Sandbox
Back to Radar

Concurrent FileSystemCache Writes Can Corrupt Fetch-Cache JSON On A Shared Filesystem

Non-atomic writes in MultiFileWriter.append() can leave partial or invalid JSON in .next/cache/fetch-cache under concurrent writes; fix by writing to a temporary file and atomically renaming it into place.

highConfidence 92%Next.jsAffected V15.5.15Affected V16.4.0-Canary.9

Origin Analysis

MultiFileWriter.append() calls this.fs.writeFile(filePath, data) directly on the final cache path. Without a temporary file + rename, concurrent writers can truncate and overwrite the same destination, allowing readers to observe partial or mixed JSON documents. Next.js already has a write-atomic utility, but it is not used in this runtime FileSystemCache path.
1. Clone https://github.com/Little-Working/nextjs-shared-cache-race-repro\n2. Run corepack enable && pnpm install\n3. Run pnpm repro\n4. The script runs two concurrent MultiFileWriter instances writing to the same cache path through a slow filesystem adapter while another task reads and parses that path. Observe parseErrors > 0 and possible invalid JSON.

Fixing Code Block

Edge Case Audit

Atomic rename is not guaranteed on all network filesystems (e.g., some Windows SMB configurations) and may require FILE_RENAME_REPLACE semantics. Concurrent updates remain last-writer-wins, but no corruption occurs. If rename fails after the temporary write, the temp file may leak; a production fix should include a cleanup step. Rollback: revert to the original writeFile call, but re-introduces the race.

Ecosystem Topology