Drop the trailing period from the node-shaped AbortError message

[robobun]

Problem

• Every node-compat API that rejects or emits node's AbortError (name: "AbortError", code: "ABORT_ERR", cause: signal.reason) uses the message "The operation was aborted.". Node's message is "The operation was aborted", with no period (lib/internal/errors.js, class AbortError, v26.3.0 L979-L988).
• Affected: timers/promises, fs/fs.promises { signal }, fs.promises.watch, events.once/on, streams (addAbortSignal, finished, Symbol.asyncDispose, ...), child_process, net, http2 client requests, and Bun.spawn({ signal }), since they all build the error through $makeAbortError or Bun__wrapAbortError.
• Cause: both helpers (src/jsc/bindings/ErrorCode.cpp:1748, :1751, :1769, :1772) take their default message from the OperationWasAborted common string, defined with the period in src/jsc/bindings/BunCommonStrings.h:40.
• History: before Avoid creating temporary strings when throwing errors #17179, $makeAbortError defaulted to the period-less text. That PR introduced the common string (with the period) because it was also used for the CommonAbortReason::UserAbort error, whose WebIDL text does end in a period, and patched the two tests that noticed. The CommonAbortReason path has since moved to createDOMException with its own literals (ErrorCode.cpp:1781-1787, DOMException.cpp:53), so the common string is now only read by the two node-shaped paths.

$ node -e "require('timers/promises').setTimeout(10,null,{signal:AbortSignal.abort()}).catch(e=>console.log(JSON.stringify(e.message)))"
"The operation was aborted"
$ bun  -e "require('timers/promises').setTimeout(10,null,{signal:AbortSignal.abort()}).catch(e=>console.log(JSON.stringify(e.message)))"
"The operation was aborted."

Fix

• BunCommonStrings.h: the OperationWasAborted literal loses its period; that is the whole runtime change. Both consumers ($makeAbortError with and without arguments, Bun__wrapAbortError with and without a cause) read this one string, so every caller listed above changes together.
• Correct because the string's only readers produce node's AbortError, and for those node's observed text is the spec. The DOMException defaults (signal.reason, fetch aborts, AbortSignal.timeout) are separate literals and keep their period; the tests asserting them (test/js/web/abort, test/js/web/fetch, the callback fs.watch tests, undici, serve) are unchanged and still pass.
• Tests updated for the new text, each of which fails on the unfixed build with only the message differing:
  • test/js/node/test/parallel/test-timers-promises-scheduler.js: restored to the upstream text byte for byte (blob 7caf92fdf6, the pre-Avoid creating temporary strings when throwing errors #17179 version).
  • test/js/node/fs/promises.test.js (Bun__wrapAbortError via node_fs: pre-aborted, in flight, default and custom reasons, callback API).
  • test/js/node/events/event-emitter.test.ts: the on() abort test now awaits its iteration and asserts name/code/message/cause; previously the assertion ran in a detached async function.
  • test/js/node/watch/fs.watch.test.ts (fs.promises.watch): the two assertions now use rejects.toThrow instead of an expect inside a catch.
  • test/js/node/timers.promises/timers.promises.test.ts: new block for the repro above plus setImmediate/setInterval, in-flight abort, custom reason, and a check that signal.reason.message still has its period.
  • test/js/node/stream/node-stream.test.js: Readable/Writable[Symbol.asyncDispose], the $makeAbortError() no-argument path (node: no period, no cause).
  • test/js/node/http2/node-http2.test.js and test/js/bun/spawn/spawn-signal.test.ts: the existing abort assertions gain the message (Bun__wrapAbortError via the http2 parser and via spawn).
• Verified: bun bd test on the seven .test.* files above passes; bun bd test/js/node/test/parallel/test-timers-promises-scheduler.js and test-child-process-exec-abortcontroller-promisified.js exit 0; USE_SYSTEM_BUN=1 (1.4.0) fails each modified file on the message only. git grep "operation was aborted" test leaves only DOMException assertions, all unchanged.

Background

• Two different "AbortError"s exist. The Web one is a DOMException with name === "AbortError" and numeric code === 20; it is what AbortController.abort() stores in signal.reason, and WebIDL defines its default message as "The operation was aborted.". Node's is a plain Error subclass with string code === "ABORT_ERR"; node's abortable APIs reject with it and attach signal.reason as cause, and its default message has no period.
• $makeAbortError is the private global bun's built-in JS modules call to construct node's AbortError (implemented by jsFunctionMakeAbortError in ErrorCode.cpp); Bun__wrapAbortError is the same constructor exported to Rust (AbortSignal::node_abort_error_if_aborted, the http2 parser).
• BunCommonStrings.h lists string literals that are created once per global object and reused, so an error can be built without allocating its message each time; changing the literal changes every consumer.

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 10 minutes

Limit details: You’ve used all 5 included reviews currently available under your plan.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 6e203bee-d96d-4dcb-8314-e075c7998897

📥 Commits

Reviewing files that changed from the base of the PR and between a42889a and e46e914.

📒 Files selected for processing (9)

• src/jsc/bindings/BunCommonStrings.h
• test/js/bun/spawn/spawn-signal.test.ts
• test/js/node/events/event-emitter.test.ts
• test/js/node/fs/promises.test.js
• test/js/node/http2/node-http2.test.js
• test/js/node/stream/node-stream.test.js
• test/js/node/test/parallel/test-timers-promises-scheduler.js
• test/js/node/timers.promises/timers.promises.test.ts
• test/js/node/watch/fs.watch.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 7:40 PM PT - Aug 15th, 2026}

@robobun, your commit e46e914 is building: #99016

[robobun]

Status: merged as 8c5296a. The follow-up self-review pass finished after the merge and raised nothing that needs a change here.

Reproduced on bun 1.4.0 and main (a42889a887) against node v26.3.0: every node-shaped AbortError (timers/promises, fs { signal }, events.once/on, streams, child_process, net, http2, Bun.spawn) carried "The operation was aborted."; node's text has no period. USE_SYSTEM_BUN=1 failed each modified test file on the message alone; bun bd test passed all of them, and the DOMException assertions (test/js/web/abort, test/js/web/fetch, callback fs.watch, undici, serve) were untouched and still pass.

Noticed while here, deliberately not part of this PR (tracked separately): String(abortError) in bun renders AbortError [ABORT_ERR]: ... where node renders AbortError: ... (node's AbortError is a plain Error subclass, not a makeNodeErrorWithCode error), and timers/promises exports scheduler as a plain object, so the current upstream revision of test-timers-promises-scheduler.js (which adds an ERR_ILLEGAL_CONSTRUCTOR check) cannot be vendored yet; this PR restored the vendored revision's original text instead.

[claude]

LGTM — one-character literal change bringing node's AbortError message in line with upstream, with thorough test coverage.

What was reviewed:

• Confirmed OperationWasAborted is only read by jsFunctionMakeAbortError / Bun__wrapAbortError (ErrorCode.cpp:1748-1772); the DOMException path at :1784 and DOMException.cpp:53 use their own literals and keep the period.
• Grepped remaining "The operation was aborted." assertions in test/ — all are DOMException-shaped (fetch, web/abort, serve, undici, callback fs.watch via signal.reason, and the new signal.reason.message check) and are unaffected.
• Test edits also strengthen previously-vacuous assertions (the un-awaited IIFE in the events.on AbortController test; expect-in-catch in fs.promises.watch).

Extended reasoning...

Overview

The runtime change is a single-character deletion in src/jsc/bindings/BunCommonStrings.h: the OperationWasAborted common string drops its trailing period so that node-compat APIs that build node's AbortError (code: 'ABORT_ERR', cause: signal.reason) match Node's exact default message. Eight test files are updated: one upstream node parallel test restored to its original text, five existing test files updated to assert the new message (several also strengthening previously-weak assertions), and two files gaining new coverage for the $makeAbortError() no-arg path and the timers/promises variant matrix.

Security risks

None. This is a one-character change to a user-visible error message string. No auth, crypto, parsing, or memory-safety surface is touched.

Level of scrutiny

Low. The only production change is a string literal. I verified via grep that the only readers of this common string are the two node-shaped AbortError constructors in ErrorCode.cpp (lines 1748, 1751, 1769, 1772), and that the WebIDL DOMException path (CommonAbortReason::UserAbort → createDOMException at line 1784, and DOMException.cpp:53) uses its own separate literal that retains the period. I also confirmed the callback fs.watch abort path emits signal.reason (the DOMException) directly via emit_if_aborted → s.js_reason() in node_fs_watcher.rs, so the three unchanged period-asserting tests in fs.watch.test.ts are correct as-is.

Other factors

The PR description is unusually thorough — it traces the regression to #17179, cites the Node source line, and documents USE_SYSTEM_BUN=1 verification for every changed test. The test edits go beyond a mechanical string swap: the events.on AbortController test previously ran its assertion in a detached un-awaited IIFE (so a failure would have been an unhandled rejection, not a test failure) and now awaits it; the two fs.promises.watch abort tests previously used expect inside a catch (vacuous if the promise resolved) and now use rejects.toThrow. New coverage in timers.promises.test.ts and node-stream.test.js exercises both the with-cause and no-cause $makeAbortError branches and explicitly asserts that signal.reason.message still has its period, guarding against accidentally changing the DOMException text.