Link to the code that reproduces this issue

https://github.com/AlanChauchet/test-next-memory

To Reproduce

Using the reproduction repo:

npm i -E [email protected]
bash ./scripts/perf/run-docker-memory-benchmark.sh --label next15_4_0

This completes successfully for the full 25-minute benchmark.

npm i -E [email protected]
bash ./scripts/perf/run-docker-memory-benchmark.sh --label next15_4_1

This fails after roughly 2 to 3 minutes with a JavaScript heap out-of-memory error.

npm i -E [email protected]
bash ./scripts/perf/run-docker-memory-benchmark.sh --label next16_1_6

This fails in the same way as 15.4.1.

Current vs. Expected behavior

Expected:

• 15.4.1 and later should behave similarly to 15.4.0
• memory usage should stay bounded under sustained load
• the app should complete the benchmark without a heap crash

Actual:

• 15.4.0 completes the benchmark
• 15.4.1 and 16.1.6 show rapid memory growth and crash with a JavaScript heap out-of-memory error
• in the working case, container memory usage generally stays under about 20%
• in the failing cases, memory usage reaches around 70% in less than 2 minutes before continuing toward the crash

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:48:41 PST 2026; root:xnu-12377.81.4~5/RELEASE_ARM64_T6041
  Available memory (MB): 36864
  Available CPU cores: 14
Binaries:
  Node: 22.20.0
  npm: 10.9.3
  Yarn: N/A
  pnpm: 9.15.4
Relevant Packages:
  next: 16.1.6 // Latest available version is detected (16.1.6).
  eslint-config-next: N/A
  react: 19.2.3
  react-dom: 19.2.3
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Loading UI and Streaming, Cookies, Performance

Which stage(s) are affected? (Select all that apply)

next start (local), Other (Deployed)

Additional context

Minimal reproduction details

The app is intentionally tiny. The route under test is a server component page that does only this on each request:

• calls cookies() from next/headers
• performs a server-side fetch()
• the fetch target returns JSON

The benchmark repeatedly hits that route with randomized query strings to create many distinct request URLs.

Important isolation findings

I tested the pieces independently, and the failure seems to require a specific combination:

• cookies() + fetch() to the current JSON endpoint: fails on 15.4.1 and 16.1.6
• remove cookies(), keep fetch(): succeeds on all tested versions
• remove fetch(), keep cookies(): succeeds on all tested versions
• keep cookies(), but change fetch() to a URL that does not return JSON: succeeds on all tested versions

So the regression appears only when all of the following are combined:

• request cookie access via cookies()
• a server-side fetch()
• a fetched response that returns JSON

This makes it look like the issue is caused by the interaction between these features, rather than by any one of them in isolation.

In addition, the memory profile tracks with that behavior:

• the working variants tend to remain under about 20% memory usage
• the failing variants climb to around 70% in under 2 minutes

Versions tested

• 15.4.0: works
• 15.4.1: fails
• 16.1.6: fails

This suggests a regression introduced between 15.4.0 and 15.4.1 that is still reproducible in 16.1.6.

Additional context

The reproduction repo includes:

• a Dockerized benchmark runner
• k6 load generation
• memory and process sampling
• per-run artifacts (docker-stats.csv, process-memory.csv, container.log, k6-summary.json, k6-output.log)

If helpful, I can also provide the generated logs and memory traces from successful vs failing runs.