morluto/rea

Fork 0

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

[PR #2084] [MERGED] fix(wasm): stop appending WABT remediation to unrelated runtime-root failures #5013

New issue

Closed

opened 2026-10-31 00:57:59 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:57:59 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2084
Author: @STiFLeR7
Created: 10/12/2026
Status: ✅ Merged
Merged: 10/12/2026
Merged by: @baron

Base: main ← Head: fix/wabt-runtime-root-error-message

📝 Commits (1)

e4fa638 fix(wasm): stop appending WABT remediation to unrelated runtime-root failures

📊 Changes

2 files changed (+47 additions, -1 deletions)

View changed files

📝 src/wasm/WabtArtifactProvider.test.ts (+39 -1)
📝 src/wasm/WabtFailures.ts (+8 -0)

📄 Description

Summary

inspect_wasm_artifact returns a misleading remediation when the failure has nothing to do with WABT. Fixes a bug introduced by how WabtArtifactProvider.inspect()'s configuration phase is structured (no linked issue; found via hands-on CLI testing with a real WABT 1.0.42 install, not from an existing report).

Problem and expected behavior

WabtArtifactProvider.inspect() allocates its PrivateRuntimeRoot during the same "configuration" phase used for resolving/validating the WABT tool directory. WabtFailures.ts's wabtFailure() treated every non-OwnedCommandFailure thrown during that phase as a WABT tool/directory problem and unconditionally appended "Supply WABT 1.0.42 via absolute REA_WABT_BIN_DIRECTORY; REA does not install tools." to the reason.

On a host where PrivateRuntimeRoot.create() throws PrivateRuntimeRootUnavailableError (e.g. the Windows native-authority capability is unavailable — unrelated to WABT at all), the resulting reason read:

REA Windows native controls are unavailable: ENOENT: ... manifest.json Supply WABT 1.0.42 via absolute REA_WABT_BIN_DIRECTORY; REA does not install tools.

with a fully correct, hash-verified REA_WABT_BIN_DIRECTORY already pointing at real WABT 1.0.42 binaries. Expected: the reason should describe the actual failure (the private-runtime-root capability) without implying WABT is misconfigured.

Change and scope

Classify PrivateRuntimeRootUnavailableError before the generic configuration-phase branch in WabtFailures.ts, returning an AnalysisCapabilityUnavailableError with no userMessage override. This matches the existing project convention already used for this exact error type in JavaScriptAnalysisWorker.ts and SourceMapCommand.ts — not a new pattern. Every other configuration-phase failure (missing/invalid directory, missing tool, bad version banner) is untouched and still gets the WABT-specific remediation, which is correct for those cases.

Contract and boundary impact

Semantic owner and earliest changed stage: src/wasm/WabtFailures.ts, configuration-phase error classification only.
CLI and MCP/tool-catalog contract: no schema change; inspect_wasm_artifact's error shape is unchanged (AnalysisCapabilityUnavailableError either way), only userMessage/reason content differs for this one cause type.
Provider, bridge, target-format, or platform compatibility: none.
Evidence, artifact, provenance, or reconstruction contract: none.
Process execution, authorization, cleanup, or containment impact: none.
Generated metadata/package/installation impact: none.

Evidence and regression coverage

Tests added or updated: src/wasm/WabtArtifactProvider.test.ts — new case injects a createRuntime that throws PrivateRuntimeRootUnavailableError against a directory with real stub WABT tool binaries, asserts userMessage is undefined and the message carries the real cause, not the WABT remediation.
Base reproduction: confirmed via real CLI run against a hash-verified WABT 1.0.42 Windows release before this change — see Validation below.
User-visible CLI/MCP output: before/after reason strings in Validation.
Remaining proof gaps: could not reproduce on a host where the native Windows authority addon is present (this dev checkout lacks the prebuilt artifact, same gap tracked by #287), so the "available" path through PrivateRuntimeRoot.create() on Windows is unexercised by this PR; the unit test exercises the classification logic directly instead, which is where the actual bug lives.
Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

npm run check (typecheck, lint, format:check, knip, metadata:check, verify:architecture-guards) — clean. Lint reported 854 pre-existing warnings repo-wide, 0 errors; unrelated to this change.
npm run verify:test-discovery — all 915 test files discovered exactly once, confirming the new test case didn't orphan or duplicate discovery for its file.
npx vitest run src/wasm/WabtArtifactProvider.test.ts — new test passes; the file's 9 pre-existing it.each failures are unchanged before/after this change (confirmed via git stash), caused by this checkout lacking the prebuilt Windows native addon (native/windows/build/manifest.json), not by this PR.
Real CLI repro with a hash-verified WABT 1.0.42 Windows release (REA_WABT_BIN_DIRECTORY pointed at wat2wasm/wasm-validate/wasm-objdump/wasm2wat, each confirmed reporting 1.0.42) and a real compiled .wasm module:
- Before: "reason":"REA Windows native controls are unavailable: ENOENT: no such file or directory, open '...\native\windows\build\manifest.json' Supply WABT 1.0.42 via absolute REA_WABT_BIN_DIRECTORY; REA does not install tools."
- After: "reason":"REA Windows native controls are unavailable: ENOENT: no such file or directory, open '...\native\windows\build\manifest.json'"

Compatibility, safety, and release

Breaking changes or migration steps: none.
Real Hopper/Ghidra, browser, or OS coverage: none needed; this is error-classification logic, not provider behavior.
Package or release metadata impact: none.
Security, privacy, process, or containment review: none.

Review checklist

This PR addresses a concrete problem or an agreed enhancement.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above (found via hands-on testing, no pre-existing issue).
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed (none needed here).
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2084 **Author:** [@STiFLeR7](https://github.com/STiFLeR7) **Created:** 10/12/2026 **Status:** ✅ Merged **Merged:** 10/12/2026 **Merged by:** [@baron](https://github.com/baron) **Base:** `main` ← **Head:** `fix/wabt-runtime-root-error-message` --- ### 📝 Commits (1) - [`e4fa638`](https://github.com/morluto/rea/commit/e4fa638c1c6b25d6072c8e266f2da91a6b2e09b9) fix(wasm): stop appending WABT remediation to unrelated runtime-root failures ### 📊 Changes **2 files changed** (+47 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/wasm/WabtArtifactProvider.test.ts` (+39 -1) 📝 `src/wasm/WabtFailures.ts` (+8 -0) </details> ### 📄 Description ## Summary `inspect_wasm_artifact` returns a misleading remediation when the failure has nothing to do with WABT. Fixes a bug introduced by how `WabtArtifactProvider.inspect()`'s configuration phase is structured (no linked issue; found via hands-on CLI testing with a real WABT 1.0.42 install, not from an existing report). ## Problem and expected behavior `WabtArtifactProvider.inspect()` allocates its `PrivateRuntimeRoot` during the same `"configuration"` phase used for resolving/validating the WABT tool directory. `WabtFailures.ts`'s `wabtFailure()` treated every non-`OwnedCommandFailure` thrown during that phase as a WABT tool/directory problem and unconditionally appended `"Supply WABT 1.0.42 via absolute REA_WABT_BIN_DIRECTORY; REA does not install tools."` to the reason. On a host where `PrivateRuntimeRoot.create()` throws `PrivateRuntimeRootUnavailableError` (e.g. the Windows native-authority capability is unavailable — unrelated to WABT at all), the resulting `reason` read: ``` REA Windows native controls are unavailable: ENOENT: ... manifest.json Supply WABT 1.0.42 via absolute REA_WABT_BIN_DIRECTORY; REA does not install tools. ``` with a fully correct, hash-verified `REA_WABT_BIN_DIRECTORY` already pointing at real WABT 1.0.42 binaries. Expected: the reason should describe the actual failure (the private-runtime-root capability) without implying WABT is misconfigured. ## Change and scope Classify `PrivateRuntimeRootUnavailableError` before the generic configuration-phase branch in `WabtFailures.ts`, returning an `AnalysisCapabilityUnavailableError` with no `userMessage` override. This matches the existing project convention already used for this exact error type in `JavaScriptAnalysisWorker.ts` and `SourceMapCommand.ts` — not a new pattern. Every other configuration-phase failure (missing/invalid directory, missing tool, bad version banner) is untouched and still gets the WABT-specific remediation, which is correct for those cases. ## Contract and boundary impact - Semantic owner and earliest changed stage: `src/wasm/WabtFailures.ts`, configuration-phase error classification only. - CLI and MCP/tool-catalog contract: no schema change; `inspect_wasm_artifact`'s error shape is unchanged (`AnalysisCapabilityUnavailableError` either way), only `userMessage`/`reason` content differs for this one cause type. - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: none. - Process execution, authorization, cleanup, or containment impact: none. - Generated metadata/package/installation impact: none. ## Evidence and regression coverage - Tests added or updated: `src/wasm/WabtArtifactProvider.test.ts` — new case injects a `createRuntime` that throws `PrivateRuntimeRootUnavailableError` against a directory with real stub WABT tool binaries, asserts `userMessage` is `undefined` and the message carries the real cause, not the WABT remediation. - Base reproduction: confirmed via real CLI run against a hash-verified WABT 1.0.42 Windows release before this change — see Validation below. - User-visible CLI/MCP output: before/after `reason` strings in Validation. - Remaining proof gaps: could not reproduce on a host where the native Windows authority addon *is* present (this dev checkout lacks the prebuilt artifact, same gap tracked by #287), so the "available" path through `PrivateRuntimeRoot.create()` on Windows is unexercised by this PR; the unit test exercises the classification logic directly instead, which is where the actual bug lives. - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npm run check` (typecheck, lint, format:check, knip, metadata:check, verify:architecture-guards) — clean. Lint reported 854 pre-existing warnings repo-wide, 0 errors; unrelated to this change. - `npm run verify:test-discovery` — all 915 test files discovered exactly once, confirming the new test case didn't orphan or duplicate discovery for its file. - `npx vitest run src/wasm/WabtArtifactProvider.test.ts` — new test passes; the file's 9 pre-existing `it.each` failures are unchanged before/after this change (confirmed via `git stash`), caused by this checkout lacking the prebuilt Windows native addon (`native/windows/build/manifest.json`), not by this PR. - Real CLI repro with a hash-verified WABT 1.0.42 Windows release (`REA_WABT_BIN_DIRECTORY` pointed at `wat2wasm`/`wasm-validate`/`wasm-objdump`/`wasm2wat`, each confirmed reporting `1.0.42`) and a real compiled `.wasm` module: - Before: `"reason":"REA Windows native controls are unavailable: ENOENT: no such file or directory, open '...\native\windows\build\manifest.json' Supply WABT 1.0.42 via absolute REA_WABT_BIN_DIRECTORY; REA does not install tools."` - After: `"reason":"REA Windows native controls are unavailable: ENOENT: no such file or directory, open '...\native\windows\build\manifest.json'"` ## Compatibility, safety, and release - Breaking changes or migration steps: none. - Real Hopper/Ghidra, browser, or OS coverage: none needed; this is error-classification logic, not provider behavior. - Package or release metadata impact: none. - Security, privacy, process, or containment review: none. ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above (found via hands-on testing, no pre-existing issue). - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed (none needed here). - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 00:57:59 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-11-01 21:42:39 +00:00

[PR #5013] [CLOSED] test(hopper): guard against string record reprojection in literal search #6732

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#5013

No description provided.

Rows
Columns