Next 16.3.0 emit MaxListenersExceededWarning #96973
Replies: 4 comments 6 replies
|
Confirming this reproduces on our side as well, after upgrading an app from 15.5.21 → 16.3.0. Identical warning, identical 448 occurrences in ~17 minutes on the new deployment; 0 on the previous Next 15 deployment, no other changes. I dug into it a bit and have some data that might help. TL;DR: it is not a leak. Next's per-request 1. It is not a leak, and the occurrence count proves itNode's const { EventEmitter } = require('events')
let warnings = 0
process.on('warning', (w) => { if (w.name === 'MaxListenersExceededWarning') warnings++ })
const a = new EventEmitter()
for (let i = 0; i < 30; i++) a.on('close', () => {})
// → 1 warning (not 20)
const b = new EventEmitter()
for (let i = 0; i < 15; i++) b.on('close', () => {})
// → 2 warnings totalSo 448 warnings ≈ 448 distinct 2. Reproducing it without needing to reach the thresholdThe warning only fires above 10, which makes it awkward to reproduce locally where fewer listeners are attached. You don't need to reach 10 — just lower the limit so the same code path crosses it: // lower-max-listeners.js
require('node:events').defaultMaxListeners = 5NODE_OPTIONS="--trace-warnings --require ./lower-max-listeners.js" next startThis produces the identical warning (with One caveat: because of the // dump-close-stacks.js
const http = require('node:http')
const counts = new WeakMap()
const proto = http.ServerResponse.prototype
// `once()` delegates to `on()`, `prependOnceListener()` to `prependListener()`.
// Hook only the terminal two, or every registration gets counted twice.
for (const m of ['on', 'prependListener']) {
const original = proto[m]
proto[m] = function (event, listener) {
if (event === 'close') {
const n = (counts.get(this) || 0) + 1
counts.set(this, n)
console.log(`#${n} ${this.req?.url}\n${new Error().stack}`)
}
return original.call(this, event, listener)
}
}3. Measured counts: 15.5.21 vs 16.3.0Same application, same Node (20.18.0), both served with
4. Why the number is exactly 11Node warns when the count exceeds 10, i.e. on the 11th listener. In our deployed environment something outside Next adds ~5 more on top of Next's own: Next 15 was sitting exactly at the limit, and 16's +1 pushed it over. That explains the abrupt
5. All six registrations in 16.3.0Full stacks for a single App Router page request.
Two observations:
6. SuggestionEach of the six listeners looks individually legitimate. The problem is that framework internals consume 6 of Node's default budget of 10, leaving very little headroom for anything else in the process (APM/tracing, proxies, custom instrumentation). Two directions:
Environment
|
|
Follow-up to my comment above: I've now accounted for all 11 listeners and reproduced the warning locally, without needing to lower the limit. The key finding: the warning only fires on requests that go through a Full breakdown of the 11
The three added by the rewrite proxy
Two things this rules out
If you are hitting this, check
If both, you are likely at 11 on exactly those routes. On 15.5.21 the same setup lands on 10 and stays silent. Restating the suggestionNone of the 11 registrations is wrong on its own. The issue is the budget: Next's own internals take 6 of Node's default 10, and Next's own rewrite proxy takes 3 more on proxied routes — so 9 of the 10 default slots are consumed by Next itself before any user code or instrumentation is added. Calling |
|
God |
AI slop answers ? 😅 |
|
|
Should I write an issue for Next team to investigate ? Please, also stop using AI to farm your responses. |
|
@RSickenberg “stop using AI” 😭 Bro, if the technical explanation is wrong, you should have absolutely no problem explaining why it’s wrong. Calling something “AI slop” isn't a rebuttal. It’s basically saying “I don't like how you got the answer” instead of addressing the answer itself. AI is a tool. I use it to help research, debug, cross-check and explain things. If I make a technical mistake, call it out and I'll fix it. But if your strongest counterargument is “AI bad,” then congrats—you've successfully defeated absolutely nothing. 💀 |
The technical explanation was not wrong. But I just read the last points because I know how LLMs work and generate a lot of void for nothing. Relying on a tool to do our job is not progress, it's laziness and I'm basically against it. Edit: |
|
@RSickenberg You said I was basically copying and pasting Claude's answer, but here's the funny part: I didn't use Claude. You don't know what tool I used, you don't know what parts I wrote myself, and you don't know what I researched or verified before replying. You simply assumed it was Claude and then built your argument around that assumption. And yes, there are plenty of AI tools out there. Claude is one, ChatGPT is another, and there are others too. But more importantly, the answer you see is not automatically “an AI answer” just because I used a tool while researching or writing it. I added my own reasoning and my own response to the discussion. You also said you're a developer, so you should understand this better than most: developers use tools all the time. Documentation, Stack Overflow, GitHub, debuggers, IDEs, linters, search engines, Copilot, AI assistants—you use whatever helps you investigate a problem. The important question is still the same: Was the technical explanation correct? You already said it wasn't wrong. So if you disagree with something, point out the technical mistake. I'm completely fine with that. But saying “you used Claude” when you don't actually know that isn't a technical argument. It's just an assumption. Judge the code. Judge the reasoning. Judge the evidence. Don't judge a tool you guessed I used. |
Uh oh!
There was an error while loading. Please reload this page.
I managed to pin the issue on all the deps i'm using and it leads to Next 16.3.0.
Any feedback?
All reactions