Eagerly format default AbortController abort reasons to avoid retaining canceled work
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- javascript, nodejs
- Área
- backend
Línea de trabajo
Start at the AbortController abort entry point and compare the existing workaround in lib/internal/streams/destroy.js. Reproduce the retention with an .mjs file using node --expose-gc, then verify that default reasons release retained buffers after abort notifications while caller-supplied reasons remain untouched and formatter exceptions do not escape abort().
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Could controller.abort() eagerly read the default reason’s stack, following the existing streams workaround and its original discussion?
A retained signal can keep the canceled job alive through signal → reason → V8 stack → caller’s receiver, including large buffers. This surfaced while investigating jsdom window retention.
Run this as an .mjs file with node --expose-gc. Verified on Node v26.8.2, Linux x64:
import { setImmediate } from "node:timers/promises";
class RenderJob {
input = Buffer.alloc(32 * 1024 * 1024, 1);
controller = new AbortController();
cancel() {
this.controller.abort();
return this.controller.signal;
}
}
async function retainedMiB() {
for (let i = 0; i < 5; ++i) {
await setImmediate();
global.gc();
}
return Math.round(process.memoryUsage().arrayBuffers / 1024 ** 2);
}
// Model dependencies retaining signals after the jobs are discarded.
const signals = Array.from({ length: 4 }, () => new RenderJob().cancel());
console.log(await retainedMiB()); // 128
console.log(signals.every(signal => signal.aborted)); // true
for (const signal of signals) void signal.reason.stack;
console.log(await retainedMiB()); // 0
console.log(signals.every(signal => signal.aborted)); // true
The same signals and reasons remain alive throughout; reading their stacks releases all 128 MiB.
I propose formatting only newly created default reasons, leaving caller-supplied reasons untouched. This preserves error identity and stack text with the default formatter. Formatting should follow abort notifications, and formatter exceptions should not escape abort().
GPT-6 Astra Extra High's suggested diff
- abort(reason = new DOMException('This operation was aborted', 'AbortError')) {
- abortSignal(this.#signal ??= new AbortSignal(kDontThrowSymbol), reason);
+ abort(reason = undefined) {
+ const signal = this.#signal ??= new AbortSignal(kDontThrowSymbol);
+ if (signal[kAborted]) return;
+
+ const isDefaultReason = reason === undefined;
+ if (isDefaultReason) {
+ reason = new DOMException('This operation was aborted', 'AbortError');
+ }
+
+ abortSignal(signal, reason);
+
+ if (isDefaultReason) {
+ try {
+ // Release references retained by V8's unformatted stack.
+ // See https://github.com/nodejs/node/pull/34103#issuecomment-652002364
+ reason.stack; // eslint-disable-line no-unused-expressions
+ } catch {
+ // A custom stack formatter must not make cancellation throw.
+ }
+ }
}
The tradeoffs are extra formatting work and earlier Error.prepareStackTrace execution. Custom formatters that retain call sites or throw may still retain the objects. This is the same compromise streams already makes.
Alternately, if the Node.js team has good V8 contacts, it might be good to raise this with them. It's kind of ridiculous for large objects to be retained in this way all because of Error.prepareStackTrace, in my opinion.
- Lenguaje dominante
- JavaScript
- Estrellas
- 122k
- Forks
- 37.4k
- Merge medio
- 4 d 4 h
- PR fusionados (30 d)
- 276
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de nodejs/node
-
doc
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
build
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
-
feature request
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Todos los issues de nodejs/node
Issues similares
-
bug customer-eng Durable Agents Inngest status: needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
optimization optimization:agents-md-curator
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
githubnext/gh-aw-cao#13475 ·
-
[BUG]: "Clear All" in Settings doesn't clear the saved analysis, old data comes back after reload Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
AOSSIE-Org/OrgExplorer#253 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
oxc-project/oxc#26944 ·
-
ai-observability bug team/ai-observability
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100