Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Eagerly format default AbortController abort reasons to avoid retaining canceled work

Đang mở
#66,192 1 bình luận 1 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, nodejs
Lĩnh vực
backend

Hướng nghiên cứu

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().

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
JavaScript
Star
122k
Fork
37.4k
Merge trung bình
4 ngày 4 giờ
Pull request đã merge (30 ngày)
276

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nodejs/node

Tất cả issue của nodejs/node

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.