Turbopack File cache writing completely freezes the PC

[yusifaliyevpro]

This issue has only occurred once since I started using Next.js v16.1.1 with Turbopack file caching. Today, while running the development server, my computer completely froze for about 30 seconds. It wasn’t just the app that stalled, the entire system locked up during that period.

GET /settings/email 200 in 74ms (compile: 23ms, generate-params: 16ms, render: 52ms)
○ Compiling /api/auth/[...all] ...
✓ Finished writing to filesystem cache in 29.9s
GET /api/auth/get-session 200 in 30.6s (compile: 30.3s, render: 339ms)
GET /api/auth/get-session 200 in 34ms (compile: 18ms, render: 16ms)

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
 reactCompiler: true,
 typedRoutes: true,
 cacheComponents: true,
 images: {
   formats: ["image/avif", "image/webp"],
   deviceSizes: [640, 750, 828, 1080, 1200],
   imageSizes: [16, 32, 48, 64, 96, 128],
   minimumCacheTTL: 604800,
   remotePatterns: [{ protocol: "https", hostname: "lh3.googleusercontent.com" }],
 },
 // experimental: { browserDebugInfoInTerminal: true },
};

export default nextConfig;

// api/auth/[...all]/route.ts
import { auth } from "@/lib/auth";
import { toNextJsHandler } from "better-auth/next-js";

export const { GET, POST } = toNextJsHandler(auth);

[nokia1054g]

Samesies

[mathesukkj]

same

[Ciaran0]

anyone have a solution for this?

[yusifaliyevpro]

@Ciaran0, I still couldn't get an answer, and this freezing happens almost every day now. I think the chance of it occurring increases as the project gets bigger.

[lukesandberg]

a workaround is to set experimental.turbopackFileSystemCacheForDev = false in your next config

https://nextjs.org/docs/app/api-reference/config/next-config-js/turbopackFileSystemCache

I believe this is due to memory pressure on your system which is something we are working on

[Ciaran0]

Yeah, correct

[yusifaliyevpro]

How is that even possible, they are just image files. I think this is a major issue in nextjs, and many people may be encountering this cpu problem without noticing. @lukesandberg, could you take a look?

[lukesandberg]

serving images out of public is somewhat cheaper, since otherwise we produce a router handler (small module) to serve the image in a skew protected way.

it shouldn't be expensive though, we do need to parse the image to extract some metadata and then register a route handler, but all this should be very small fixed overheads.

one time i have seen issues like this is with conflicting route handlers where two entry points try to write the same output leading to loop 😢 , but we also just report an error when this happens rather than burning cpu....

@Ciaran0 is it possible there were other files in those directories called opengraph-image or twitter-image?

what version are you on?

[slemchik03]

@lukesandberg I had experienced the same issue (we're both working on the same project with @Ciaran0) and we didn't have any duplicates of opengraph-image or twitter-image inside those directories. We're on "next": "16.1.6" (cacheComponents: true, issues persist whether I mark this route with use cache or not). This issue appeared first after migrating to Next.js 16. Feel free to ask any questions

[yusifaliyevpro]

Hi @lukesandberg, after the latest Next.js 16.2 release my worker count dropped from 19 to 17 or 9 (depend on project). I think this resolves the issue, right?

Before:

▲ Next.js 16.1.7 (Turbopack, Cache Components)
- Environments: .env

  Creating an optimized production build ...
✓ Compiled successfully in 5.8s
✓ Finished TypeScript in 5.6s
✓ Collecting page data using 19 workers in 1250.2ms
✓ Generating static pages using 19 workers (7/7) in 2.1s
✓ Finalizing page optimization in 7.2ms    

After:

▲ Next.js 16.2.0 (Turbopack)
- Environments: .env
- Cache Components enabled

  Creating an optimized production build ...
✓ Compiled successfully in 4.7s
✓ Finished TypeScript in 3.6s
✓ Collecting page data using 9 workers in 844ms
✓ Generating static pages using 9 workers (7/7) in 2.2s
✓ Finalizing page optimization in 26ms