morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #1367] [Bug] Malformed UNC source-map path aborts REA on Node builds its engines field allows #477

New issue

Closed

opened 2026-10-15 18:25:22 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:25:22 +00:00

Owner

Originally created by @CassieFox23 on GitHub (Oct 9, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1367

TL;DR: One bad line in a source map can kill REA. The line names a Windows share with a bad server name. Node 22.19 to 22.22, 24.11 to 24.15 and 26.0 abort on it. REA's engines field still allows those builds. I hit it on Node 22.22.2. Node 24.18.0 is fine.

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

rea analyze-javascript-application aborts the whole Node process. It does not return an error.

The trigger is a source map whose sources entry is a UNC path with an invalid host, such as \\bad host\share\a.js. REA passes it to pathToFileURL(path, { windows: true }). On affected Node builds, Node fails a native assertion and calls abort(). The TypeError catch in windowsFileUrl never runs.

The repo's own test hits this too. On Node 22.22.2, npm test on main (5291bca1) passes 6230 tests and still exits 1. The \\bad host\share\a.js row of "declines source references without a trustworthy file path" in tests/boundary/filesystem/sourceToBundlePaths.test.ts kills its Vitest fork worker with SIGABRT.

Reproduction

Make a folder app/maps.js/ with one file, main.js.map:

{"version":3,"file":"main.js","sources":["\\\\bad host\\share\\a.js"],"names":[],"mappings":"AAAA"}

Run rea analyze-javascript-application ./app --format json on Node 22.22.2 (REA 6.2.0 from npm).
It prints progress up to "Parsing and projecting maps.js/main.js.map". Then it aborts with exit code 134 and no JSON.
The same run on Node 24.18.0 exits 0 and returns the analysis Evidence.

The same crash in plain Node, no REA needed:

node -e 'require("node:url").pathToFileURL("\\\\bad host\\share\\a.js", { windows: true })'

On Node 24.18.0 that line throws ERR_INVALID_URL instead. A plain host (\\host\share\a.js) works on both, and the same string with { windows: false } returns an ordinary file URL on both.

Expected behavior

The source reference resolves as unresolved, the way the test expects. The analysis finishes and the process stays up. npm test passes on every Node version engines admits.

Impact and scope

Affected Node builds: 22.19.0 to 22.22.x, 24.11.0 to 24.15.x, and 26.0.0. Node fixed the crash in 22.23.0, 24.16.0 and 26.1.0 (nodejs/node#62546, fix in nodejs/node#62574, merged 2026-04-30). I read src/node_url.cc at the tags: 22.22.2, 24.11.0, 24.15.0 and 26.0.0 have CHECK(out->set_hostname(hostname.ToStringView())) at line 171; 22.23.0, 24.16.0 and 26.1.0 replace it with if (!out->set_hostname(...)) return ThrowInvalidURL(...).
REA's engines field still allows all of those builds: ^22.19.0 || ^24.11.0 || >=26.0.0.
One bad source map in an analyzed app takes down the CLI run. The MCP server shares the code path, so I'd expect it to go down the same way. I did not test MCP.
Not affected: 22.23.0+, 24.16.0+ and 26.1.0+, going by the Node fix. I ran 22.22.2, 22.23.1 and 24.18.0. On 22.23.1 the same CLI repro exits 0. The reference comes back unresolved, with the reason "Source reference is not a valid URL or filesystem path."

REA version

6.2.0 from npm for the CLI runs. main at 5291bca1 for the test suite.

Runtime and platform

Node 22.22.2 (a leftover Fedora 43 nodejs build) with npm 10.9.7; Node 24.18.0 with npm 11.16.0 as the control. Nobara 44 (Fedora 44 base), Linux x86-64.

Target and artifact context

A folder with one source map. No real app needed.

Interface

CLI

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

The abort, identical from the CLI, the Vitest worker and plain Node on 22.22.2:

  #  node[1912785]: static void node::url::BindingData::PathToFileURL(const v8::FunctionCallbackInfo<v8::Value>&) at ../../src/node_url.cc:171
  #  Assertion failed: out->set_hostname(hostname.ToStringView())

----- Native stack trace -----

 1: 0x7fba2d427767 node::Assert(node::AssertionInfo const&) [/lib64/libnode.so.127]

npm test on Node 22.22.2, main 5291bca1:

Error: Worker exited unexpectedly with signal SIGABRT during started state while running test file tests/boundary/filesystem/sourceToBundlePaths.test.ts

Test Files  691 passed | 11 skipped (703)
     Tests  6230 passed | 89 skipped (6325)
    Errors  1 error
  Duration  566.42s

On Node 24.18.0 with npm 11.16.0, same commit, npm run test:focused -- tests/boundary/filesystem/sourceToBundlePaths.test.ts passes all 53 tests in about 2 s, and the full npm test is green:

Test Files  692 passed | 11 skipped (703)
     Tests  6236 passed | 89 skipped (6325)
  Duration  471.64s

Typed outcome or recovery expected

An unresolved result, with the reason REA already has for this case: "Source reference is not a valid URL or filesystem path." Not a process abort. For the test suite: a green run on every admitted Node version, or a version-gated skip that links the Node issue.

Analysis or suspected cause

This is from reading the source. It is not a tested fix.

The call came in with #1215 (windowsFileUrl in src/domain/javascript/javascriptSourceMapPaths.ts). It wraps pathToFileURL(path, { windows: true }) in a try/catch for TypeError. On affected Node builds the C++ binding asserts instead of throwing. The catch never runs and the process dies.
CI runs most jobs on .nvmrc (24.18.0), which has the Node fix. The only Node 22.19.0 step in ci.yml runs three directory-identity tests. That would explain why CI stays green.
Two possible fixes. One: raise the engines floor to ^22.23.0 || ^24.16.0 || >=26.1.0. Two: check the UNC host before calling pathToFileURL, for example with URL.parse on file://<host>/, and return null when it fails.

Additional context

Everything above was run on one Linux box with both Node builds side by side, same source map, same REA build.

🤖 Generated with Claude Code (Fable 5.1 and Opus 5.5) 🦊

Originally created by @CassieFox23 on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1367 **TL;DR:** One bad line in a source map can kill REA. The line names a Windows share with a bad server name. Node 22.19 to 22.22, 24.11 to 24.15 and 26.0 abort on it. REA's `engines` field still allows those builds. I hit it on Node 22.22.2. Node 24.18.0 is fine. ### Before submitting - [X] I searched the open and closed issues for a related report. - [X] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior `rea analyze-javascript-application` aborts the whole Node process. It does not return an error. The trigger is a source map whose `sources` entry is a UNC path with an invalid host, such as `\\bad host\share\a.js`. REA passes it to `pathToFileURL(path, { windows: true })`. On affected Node builds, Node fails a native assertion and calls `abort()`. The `TypeError` catch in `windowsFileUrl` never runs. The repo's own test hits this too. On Node 22.22.2, `npm test` on main (`5291bca1`) passes 6230 tests and still exits 1. The `\\bad host\share\a.js` row of "declines source references without a trustworthy file path" in `tests/boundary/filesystem/sourceToBundlePaths.test.ts` kills its Vitest fork worker with SIGABRT. ### Reproduction 1. Make a folder `app/maps.js/` with one file, `main.js.map`: ```json {"version":3,"file":"main.js","sources":["\\\\bad host\\share\\a.js"],"names":[],"mappings":"AAAA"} ``` 2. Run `rea analyze-javascript-application ./app --format json` on Node 22.22.2 (REA 6.2.0 from npm). 3. It prints progress up to "Parsing and projecting maps.js/main.js.map". Then it aborts with exit code 134 and no JSON. 4. The same run on Node 24.18.0 exits 0 and returns the analysis Evidence. The same crash in plain Node, no REA needed: ```sh node -e 'require("node:url").pathToFileURL("\\\\bad host\\share\\a.js", { windows: true })' ``` On Node 24.18.0 that line throws `ERR_INVALID_URL` instead. A plain host (`\\host\share\a.js`) works on both, and the same string with `{ windows: false }` returns an ordinary file URL on both. ### Expected behavior The source reference resolves as `unresolved`, the way the test expects. The analysis finishes and the process stays up. `npm test` passes on every Node version `engines` admits. ### Impact and scope - **Affected Node builds:** 22.19.0 to 22.22.x, 24.11.0 to 24.15.x, and 26.0.0. Node fixed the crash in 22.23.0, 24.16.0 and 26.1.0 (nodejs/node#62546, fix in nodejs/node#62574, merged 2026-04-30). I read `src/node_url.cc` at the tags: 22.22.2, 24.11.0, 24.15.0 and 26.0.0 have `CHECK(out->set_hostname(hostname.ToStringView()))` at line 171; 22.23.0, 24.16.0 and 26.1.0 replace it with `if (!out->set_hostname(...)) return ThrowInvalidURL(...)`. - **REA's `engines` field** still allows all of those builds: `^22.19.0 || ^24.11.0 || >=26.0.0`. - **One bad source map** in an analyzed app takes down the CLI run. The MCP server shares the code path, so I'd expect it to go down the same way. I did not test MCP. - **Not affected:** 22.23.0+, 24.16.0+ and 26.1.0+, going by the Node fix. I ran 22.22.2, 22.23.1 and 24.18.0. On 22.23.1 the same CLI repro exits 0. The reference comes back `unresolved`, with the reason "Source reference is not a valid URL or filesystem path." ### REA version 6.2.0 from npm for the CLI runs. main at `5291bca1` for the test suite. ### Runtime and platform Node 22.22.2 (a leftover Fedora 43 `nodejs` build) with npm 10.9.7; Node 24.18.0 with npm 11.16.0 as the control. Nobara 44 (Fedora 44 base), Linux x86-64. ### Target and artifact context A folder with one source map. No real app needed. ### Interface CLI ### Earliest failure stage Artifact or evidence registration ### Relevant output or evidence The abort, identical from the CLI, the Vitest worker and plain Node on 22.22.2: ```text # node[1912785]: static void node::url::BindingData::PathToFileURL(const v8::FunctionCallbackInfo<v8::Value>&) at ../../src/node_url.cc:171 # Assertion failed: out->set_hostname(hostname.ToStringView()) ----- Native stack trace ----- 1: 0x7fba2d427767 node::Assert(node::AssertionInfo const&) [/lib64/libnode.so.127] ``` `npm test` on Node 22.22.2, main `5291bca1`: ```text Error: Worker exited unexpectedly with signal SIGABRT during started state while running test file tests/boundary/filesystem/sourceToBundlePaths.test.ts Test Files 691 passed | 11 skipped (703) Tests 6230 passed | 89 skipped (6325) Errors 1 error Duration 566.42s ``` On Node 24.18.0 with npm 11.16.0, same commit, `npm run test:focused -- tests/boundary/filesystem/sourceToBundlePaths.test.ts` passes all 53 tests in about 2 s, and the full `npm test` is green: ```text Test Files 692 passed | 11 skipped (703) Tests 6236 passed | 89 skipped (6325) Duration 471.64s ``` ### Typed outcome or recovery expected An `unresolved` result, with the reason REA already has for this case: "Source reference is not a valid URL or filesystem path." Not a process abort. For the test suite: a green run on every admitted Node version, or a version-gated skip that links the Node issue. ### Analysis or suspected cause This is from reading the source. It is not a tested fix. - The call came in with #1215 (`windowsFileUrl` in `src/domain/javascript/javascriptSourceMapPaths.ts`). It wraps `pathToFileURL(path, { windows: true })` in a `try/catch` for `TypeError`. On affected Node builds the C++ binding asserts instead of throwing. The catch never runs and the process dies. - CI runs most jobs on `.nvmrc` (24.18.0), which has the Node fix. The only Node 22.19.0 step in `ci.yml` runs three directory-identity tests. That would explain why CI stays green. - Two possible fixes. One: raise the `engines` floor to `^22.23.0 || ^24.16.0 || >=26.1.0`. Two: check the UNC host before calling `pathToFileURL`, for example with `URL.parse` on `file://<host>/`, and return `null` when it fails. ### Additional context Everything above was run on one Linux box with both Node builds side by side, same source map, same REA build. 🤖 Generated with Claude Code (Fable 5.1 and Opus 5.5) 🦊

bsakaguchi

2026-10-15 18:25:22 +00:00

closed this issue
added the
area: build

bug
labels

bsakaguchi commented

2026-10-15 18:25:23 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 9, 2026):

TL;DR: Confirmed fixed on main. Thanks, Yi-111-a and morluto.

I ran merged main (f504c2a3). The \\bad host\share\a.js map now resolves as unresolved and the CLI exits 0. The U+00AD and U+200C hosts from the review do the same. A plain \\server\share host still resolves. The new sourceMapUncHosts test file passes here, 11 cases.

Test setup

Box: Linux
Node: 22.22.2, the official tarball

🤖 Generated with Claude Code (Fable 5.1) 🦊

@CassieFox23 commented on GitHub (Oct 9, 2026): **TL;DR:** Confirmed fixed on main. Thanks, Yi-111-a and morluto. I ran merged main (f504c2a3). The `\\bad host\share\a.js` map now resolves as `unresolved` and the CLI exits 0. The U+00AD and U+200C hosts from the review do the same. A plain `\\server\share` host still resolves. The new `sourceMapUncHosts` test file passes here, 11 cases. <details> <summary>Test setup</summary> - Box: Linux - Node: 22.22.2, the official tarball </details> 🤖 Generated with Claude Code (Fable 5.1) 🦊

bsakaguchi referenced this issue

2026-10-16 21:13:26 +00:00

[PR #477] [MERGED] fix: consolidate boundary ownership and cleanup failure paths #2020

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#477

No description provided.

Rows
Columns