morluto/rea

Fork 0

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

[GH-ISSUE #2257] [Bug] Windows: intermittent "Open Windows path component failed [C:\] (Win32 32)" fails analyze-javascript-application as non-retryable capability_unavailable #746

New issue

Closed

opened 2026-10-15 18:27:54 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-15 18:27:54 +00:00

Owner

Originally created by @Ashen00001 on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2257

Before submitting

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

Area

CLI

Observed behavior

rea analyze-javascript-application <dir> --json on a Windows 11 x64 host failed once while parsing background.js (file 14 of 22). The reason was a sharing violation (Win32 32) on the path component C:\ inside REA's Windows native controls. The command exited 1, and the error was classified as capability_unavailable / unsupported_provider with retryable: false.

Every other run against the same directory succeeded: 11 runs in total, 1 failure (the run before the failure also succeeded). So this looks transient, but REA reports it as a permanent "this analysis is unavailable for the current target".

Reproduction

Install portable Node 24.21.0, then npm install --global rea-agents@latest (6.4.0).
Run rea analyze-javascript-application "<user-profile>\AppData\Local\Microsoft\Edge\User Data\Profile 2\Extensions\<id>\<version>" --json against an unpacked MV3 browser extension (8 JS files, about 7 MB total, the largest 5.4 MB). The failing run was started from Git Bash as node <npm-prefix>/node_modules/rea-agents/scripts/rea.mjs analyze-javascript-application "<same path>" --json.
The second run, a few minutes after install, failed as below. 10 other runs against the same directory succeeded (about 1.5-3 min each), including 2 with the exact same mixed-separator path string the failing run used. 2 runs against copies of the directory in other folders also succeeded.

I can't give a deterministic repro. I'm reporting it mainly because of the classification.

Expected behavior

Either the analysis succeeds, or a transient Win32 sharing violation (ERROR_SHARING_VIOLATION, 32) is surfaced as a retryable/transient error rather than capability_unavailable + unsupported_provider + retryable: false. The current wording tells the caller the target or host is unsupported, which made me assume REA could not work on this machine at all.

Impact and scope

The whole JavaScript application analysis is lost. The partial observation only contains the inventory.
No rea-native-probe-* directories were left in %TEMP% (checked after the failure).
I did not see any evidence-integrity problem. Later runs of the same target completed without error and parsed all 22 files.

REA version

6.4.0 (npm global)

Runtime and platform

Node 24.21.0 (official portable win-x64 zip); Windows 11 Pro 10.0.26200 x64 (Surface Pro 10); standard non-admin user on an organization-managed device; C: is local NTFS

Target and artifact context

Unpacked Chromium MV3 extension directory (JS, JSON, PNG, CSS, WOFF2); no ASAR

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

error: "JavaScript application analysis failed"
code: "capability_unavailable"
category: "unsupported_provider"
message: "This analysis is unavailable for the current target. Choose another analysis or target."
retryable: false
details.provider_id: "javascript-static-analysis"
details.operation: "analyze_javascript_application"
details.reason: "REA Windows native controls are unavailable: Open Windows path component failed [C:\] (Win32 32): The process cannot access the file because it is being used by another process."
limitations[]: "Source analysis was interrupted: Provider javascript-static-analysis cannot execute analyze_javascript_application: REA Windows native controls are unavailable: Open Windows path component failed [C:\] (Win32 32): ..."
last progress line: "Parsing and projecting background.js (14/22)"

Typed outcome or recovery expected

A retryable/transient error (for example retryable: true and a category other than unsupported_provider), so a caller knows to rerun instead of concluding the host or target is unsupported.

Analysis or suspected cause

Hypothesis, not verified.

The reason string is built in the catch of loadWindowsNativeAuthority (dist/windows/WindowsNativeLoader.js). The manifest and hash checks wouldn't raise a Win32 error, so the throw most likely came from loading the addon or from binding.call("inspect", []). A failed load is also cached (cached ??= ...) for the life of the process.

A share mode that excludes FILE_SHARE_WRITE/DELETE on a path component like C:\ would make the open fail whenever another process briefly holds that component with an incompatible mode. On an organization-managed device, endpoint or indexing software are candidates. Path separators seem to be ruled out: the failing run used mixed \ and / separators, but two later runs with the identical string succeeded. Possibly related to #1701 (a different Win32 error from the same self-test).

Additional context

Suggestions: retry the inspect self-test a few times on Win32 32 before giving up; don't cache a failed native-authority load for the life of the process; and classify sharing violations as transient in the error contract.

Originally created by @Ashen00001 on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2257 ### 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 CLI ### Observed behavior `rea analyze-javascript-application <dir> --json` on a Windows 11 x64 host failed once while parsing `background.js` (file 14 of 22). The reason was a sharing violation (Win32 32) on the path component `C:\` inside REA's Windows native controls. The command exited 1, and the error was classified as `capability_unavailable` / `unsupported_provider` with `retryable: false`. Every other run against the same directory succeeded: 11 runs in total, 1 failure (the run before the failure also succeeded). So this looks transient, but REA reports it as a permanent "this analysis is unavailable for the current target". ### Reproduction 1. Install portable Node 24.21.0, then `npm install --global rea-agents@latest` (6.4.0). 2. Run `rea analyze-javascript-application "<user-profile>\AppData\Local\Microsoft\Edge\User Data\Profile 2\Extensions\<id>\<version>" --json` against an unpacked MV3 browser extension (8 JS files, about 7 MB total, the largest 5.4 MB). The failing run was started from Git Bash as `node <npm-prefix>/node_modules/rea-agents/scripts/rea.mjs analyze-javascript-application "<same path>" --json`. 3. The second run, a few minutes after install, failed as below. 10 other runs against the same directory succeeded (about 1.5-3 min each), including 2 with the exact same mixed-separator path string the failing run used. 2 runs against copies of the directory in other folders also succeeded. I can't give a deterministic repro. I'm reporting it mainly because of the classification. ### Expected behavior Either the analysis succeeds, or a transient Win32 sharing violation (ERROR_SHARING_VIOLATION, 32) is surfaced as a retryable/transient error rather than `capability_unavailable` + `unsupported_provider` + `retryable: false`. The current wording tells the caller the target or host is unsupported, which made me assume REA could not work on this machine at all. ### Impact and scope - The whole JavaScript application analysis is lost. The partial observation only contains the inventory. - No `rea-native-probe-*` directories were left in `%TEMP%` (checked after the failure). - I did not see any evidence-integrity problem. Later runs of the same target completed without error and parsed all 22 files. ### REA version 6.4.0 (npm global) ### Runtime and platform Node 24.21.0 (official portable win-x64 zip); Windows 11 Pro 10.0.26200 x64 (Surface Pro 10); standard non-admin user on an organization-managed device; C: is local NTFS ### Target and artifact context Unpacked Chromium MV3 extension directory (JS, JSON, PNG, CSS, WOFF2); no ASAR ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence ```text error: "JavaScript application analysis failed" code: "capability_unavailable" category: "unsupported_provider" message: "This analysis is unavailable for the current target. Choose another analysis or target." retryable: false details.provider_id: "javascript-static-analysis" details.operation: "analyze_javascript_application" details.reason: "REA Windows native controls are unavailable: Open Windows path component failed [C:\] (Win32 32): The process cannot access the file because it is being used by another process." limitations[]: "Source analysis was interrupted: Provider javascript-static-analysis cannot execute analyze_javascript_application: REA Windows native controls are unavailable: Open Windows path component failed [C:\] (Win32 32): ..." last progress line: "Parsing and projecting background.js (14/22)" ``` ### Typed outcome or recovery expected A retryable/transient error (for example `retryable: true` and a category other than `unsupported_provider`), so a caller knows to rerun instead of concluding the host or target is unsupported. ### Analysis or suspected cause Hypothesis, not verified. The reason string is built in the `catch` of `loadWindowsNativeAuthority` (`dist/windows/WindowsNativeLoader.js`). The manifest and hash checks wouldn't raise a Win32 error, so the throw most likely came from loading the addon or from `binding.call("inspect", [])`. A failed load is also cached (`cached ??= ...`) for the life of the process. A share mode that excludes FILE_SHARE_WRITE/DELETE on a path component like `C:\` would make the open fail whenever another process briefly holds that component with an incompatible mode. On an organization-managed device, endpoint or indexing software are candidates. Path separators seem to be ruled out: the failing run used mixed `\` and `/` separators, but two later runs with the identical string succeeded. Possibly related to #1701 (a different Win32 error from the same self-test). ### Additional context Suggestions: retry the `inspect` self-test a few times on Win32 32 before giving up; don't cache a failed native-authority load for the life of the process; and classify sharing violations as transient in the error contract.

bsakaguchi

2026-10-15 18:27:54 +00:00

closed this issue
added the
P1: high

bug
labels

bsakaguchi commented

2026-10-15 18:27:55 +00:00

Author

Owner

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026):

Triage note: I couldn't reproduce this here because it needs Windows (I'm on macOS) and the failure is intermittent, so I'm skipping a fix. Source pointers for whoever can run it, current main ad08510a1:

The Win32 32 text comes from openComponent in native/windows/src/filesystem.cc. It opens each path component, here C:\, with FILE_LIST_DIRECTORY and share mode FILE_SHARE_READ. A concurrent opener holding write/delete access on that component would produce ERROR_SHARING_VIOLATION.
In loadWindowsNativeAuthority (src/windows/WindowsNativeLoader.ts), a failure inside the self-test binding.call("inspect", []) is already returned as retryable: true with the prefix "REA Windows native self-test failed". The reported reason uses the outer prefix, "REA Windows native controls are unavailable", which has no retryable flag and is what ends up as capability_unavailable / retryable: false. So this failure appears to have escaped through a path other than that inner try. Finding which one, and whether a transient sharing violation should be classified as retryable there, needs a Windows run with the native call stack.

Possibly related: #2196 and #1701 (the native self-test failing with Win32 5 on its probe directory).

@kaoru0822-kitauji commented on GitHub (Oct 12, 2026): Triage note: I couldn't reproduce this here because it needs Windows (I'm on macOS) and the failure is intermittent, so I'm skipping a fix. Source pointers for whoever can run it, current main ad08510a1: - The Win32 32 text comes from `openComponent` in `native/windows/src/filesystem.cc`. It opens each path component, here `C:\`, with `FILE_LIST_DIRECTORY` and share mode `FILE_SHARE_READ`. A concurrent opener holding write/delete access on that component would produce `ERROR_SHARING_VIOLATION`. - In `loadWindowsNativeAuthority` (`src/windows/WindowsNativeLoader.ts`), a failure inside the self-test `binding.call("inspect", [])` is already returned as `retryable: true` with the prefix "REA Windows native self-test failed". The reported reason uses the outer prefix, "REA Windows native controls are unavailable", which has no `retryable` flag and is what ends up as `capability_unavailable` / `retryable: false`. So this failure appears to have escaped through a path other than that inner `try`. Finding which one, and whether a transient sharing violation should be classified as retryable there, needs a Windows run with the native call stack. Possibly related: #2196 and #1701 (the native self-test failing with Win32 5 on its probe directory).

bsakaguchi commented

2026-10-15 18:27:55 +00:00

Author

Owner

@Ashen00001 commented on GitHub (Oct 12, 2026):

Thanks for digging in. I think the "other path" is just a version difference: I was on the published rea-agents 6.4.0 (still npm latest), and its dist/windows/WindowsNativeLoader.js has a single try/catch with binding.call("inspect", []) inside it. The inner try that returns retryable: true / "REA Windows native self-test failed" isn't in 6.4.0, so the outer "controls are unavailable" prefix is expected there. That suggests main already fixes the classification part once it's released. Happy to retest on the next release.

@Ashen00001 commented on GitHub (Oct 12, 2026): Thanks for digging in. I think the "other path" is just a version difference: I was on the published rea-agents 6.4.0 (still npm `latest`), and its `dist/windows/WindowsNativeLoader.js` has a single try/catch with `binding.call("inspect", [])` inside it. The inner try that returns `retryable: true` / "REA Windows native self-test failed" isn't in 6.4.0, so the outer "controls are unavailable" prefix is expected there. That suggests main already fixes the classification part once it's released. Happy to retest on the next release.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:02:23 +00:00

[GH-ISSUE #1065] [Feature] Roadmap: improve MCP usability and performance under bounded resources #390

bsakaguchi referenced this issue

2026-10-16 21:15:44 +00:00

[PR #749] [MERGED] fix(javascript): expose result schema failures #2211

bsakaguchi referenced this issue

2026-10-16 21:16:38 +00:00

[PR #839] [MERGED] fix(javascript): analyze sources containing empty string literals #2277