nextjs - 💡(How to fix) Fix Memory leak fix from canary (PRs #88577, #89040) still not in any 16.x stable release 45+ days later — production OOMs ongoing on 16.2.4

Link to the code that reproduces this issue

https://github.com/Tib-Gridello/nextjs-memory-leak-repro

(Originally used in #90898. Still reproduces on current stable 16.2.4.)

To Reproduce

1. npm i [email protected] (latest stable at the time of filing, released 2026-04-15)
2. Run the production server and send modest traffic — or even leave it idle
3. Observe process.memoryUsage().arrayBuffers grow monotonically
4. npm i [email protected] → growth disappears, memory stabilises
5. WriteWrap._chunks retainer chain is the same one documented in #90898

Current vs. Expected behavior

Current (as of 2026-04-20): All 16.x stable releases — 16.0.x, 16.1.x, 16.2.0, 16.2.1, 16.2.2, 16.2.3, 16.2.4 — ship without the fixes from #88577 (register both tee'd response clones with FinalizationRegistry) and #89040 (enforce LRU minimum size). Production services on stable slowly accumulate arrayBuffers until OOM. The only way to avoid this today is to pin a 16.3.0-canary.* in production, which isn't acceptable for many teams.

Expected: A stable release in the 16.x line containing these two fixes.

Real-world impact (production data)

Redacted excerpt from a Render service ([email protected], Node 22, next start, 512 MiB, single instance, output default — not standalone, no cacheComponents):

• 4 confirmed `oomKilled` events in the last 7 days (Render event type `server_failed`, reason `oomKilled { memoryLimit: "512Mi" }`).
• Memory after fresh boot: ~245 MiB. Steady climb of ~30 MiB/hour at effectively 0% CPU, ~1 MB/30min bandwidth. Reaches 512 MiB cap in ~8 hours and gets SIGKILLed. Repeats.
• Profile is classic "idle leak not proportional to request volume" — matches the `tee'd response clone never finalized + LRU zero-size bug` fingerprint from #90898 exactly.

This shows the leak is not limited to `output: standalone` or `cacheComponents` configs (#92287). Any Next.js 16 server with internal `fetch` usage or route handlers forwarding upstream response bodies is affected.

Context — what's already been filed

• #85914 — closed 2026-01-19 as "completed" (fix in canary, not released)
• #90431 — closed 2026-02-24 as "completed"
• #90898 — closed 2026-03-09 as "completed" (explicit confirmation that #88577 + #89040 are in canary but no 16.x stable)
• #90897 — backport PR closed unmerged on 2026-03-04 with the maintainer note: "a new minor release will contain it for sure"
• #92287 — still open, narrowly scoped to `standalone + cacheComponents`

Ask

Not filing this as a new bug — the bug is identified and the fixes exist. Filing it because it's been 45+ days since the canary fix landed, and every 16.x stable release since — including `16.2.4` three days ago — has been cut without it, while real production services continue to OOM every few hours.

Concrete questions for the team:

1. Is a `16.2.5` backport on the table, or is the intent to ship only via `16.3.0` stable?
2. If `16.3.0` only, is there a rough ETA users can plan against?
3. In the meantime, is running `[email protected].*` in production the recommended workaround, or is there a safer path?

Provide environment information

```bash Operating System: Platform: linux Arch: amd64 (Render Starter instance) Binaries: Node: 22.x pnpm: 10.6.1 Relevant Packages: next: 16.2.4 (affected) / 16.3.0-canary.2 (not affected) react: 19.2.5 react-dom: 19.2.5 typescript: 6.0.3 Next.js Config: output: N/A (NOT using 'standalone') cacheComponents: false ```

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

Performance

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

Other (Deployed)