test_runner: allow adapters to handle individual unhandled promise rejections

What is the problem this feature will solve?

(AI disclosure: text written by GPT-6 Astra Extra High, then read, tweaked, and signed-off on by @domenic.)

We are migrating jsdom's tests to node:test. Our Web Platform Tests adapter runs each WPT file inside a jsdom instance, waits for the embedded testharness.js harness to finish, and checks its results against our expectations.

Some WPTs deliberately produce unhandled rejections in iframe windows. These do not necessarily constitute failures of the parent window's test harness. Other rejections should become harness failures, which the adapter needs to evaluate against expected failures for unimplemented functionality.

Currently, node:test fails and aborts the enclosing test when it observes an unhandled rejection, before our adapter can finish evaluating the WPT. Adding our own process.on("unhandledRejection") listener does not prevent the test runner from independently failing the test.

We need a supported way for an embedded test harness to take responsibility for selected rejections, while preserving normal test-runner failure handling for unrelated rejections.

What is the feature you are proposing to solve the problem?

A per-test hook that can handle individual unhandled rejections before the test runner automatically fails or aborts the test.

For example, the API could look like this:

test("embedded harness", {
  onUnhandledRejection(reason, promise) {
    if (!adapter.ownsPromise(promise)) {
      return false;
    }

    adapter.recordUnhandledRejection(reason, promise);
    return true;
  }
}, async () => {
  await adapter.run();
  adapter.assertExpectedResults();
});

The important capabilities would be:

• The hook receives both the rejection reason and the actual promise, allowing the adapter to identify ownership.
• Returning true indicates that the adapter accepts responsibility for the rejection. The test runner does not automatically fail or abort the test for that rejection.
• Returning false or undefined preserves current behavior. Throwing from the hook fails the test.

What alternatives have you considered?

Stuff that doesn't work that we tried

• Adding a process-level unhandledRejection listener, including a prepended listener. The test runner still receives the event and fails the test.
• Using --unhandled-rejections=none. This suppresses warnings, but does not prevent the test runner from failing the test.
• Using expectFailure. This still lets the runner fail and abort the test instead of letting the embedded harness finish evaluating its results.

Stuff that works but is icky

• Wrapping process.emit to intercept selected rejection events. Small probes work on Node 22, 24, and 26 while preserving failure handling for unrelated rejections, but this requires monkeypatching and depends on the runner's reporting mechanism.
• Using node:domain. This can redirect rejections, but the API is deprecated and affects more than rejection reporting.
• Running the embedded harness in a separate process. This provides control over rejection handling, but adds process management and communication infrastructure.
• Skipping the affected tests. This avoids the immediate failures but loses regression coverage compared to mocha.

Bắt đầu với cách runner node:test hiện xử lý các rejection chưa được xử lý, sử dụng kịch bản bộ điều hợp WPT của jsdom và các phương án thay thế ở cấp process được liệt kê làm ngữ cảnh tái hiện. Xác định phạm vi kiểm thử cho các rejection đã được nhận, chưa được nhận, gây lỗi và đến muộn; công việc được xem là hoàn tất khi các bài kiểm thử tập trung xác nhận rằng các rejection đã được nhận không hủy bỏ test bao quanh, trong khi các rejection không liên quan vẫn giữ nguyên hành vi hiện tại.