[GH-ISSUE #2528] fix(frida): recovered adapter still reports its previous load failure #844

New issue

Closed

opened 2026-10-15 18:28:56 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

Originally created by @coygeek on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2528

Summary

After a Frida adapter load fails once and a subsequent attempt succeeds, device discovery works but the manager still reports the original load failure. Capability discovery reads this obsolete failure and classifies the Frida tools as unavailable, with an instruction to repair the installation and restart.

Steps to reproduce

Use the tested main revision and a fake device manager whose device enumeration succeeds. This reproduction tests adapter loading without opening a native target or remote connection.

Construct the Frida instrumentation manager with a loader that throws Error("transient load failure") on its first call and returns the fake manager on its second call.
Call listDevices(). It returns a failed result and the availability failure records the loader error.
Call listDevices() again. It succeeds and returns the fake device list.
Read availabilityFailure(). It still returns { providerId: "frida", reason: "transient load failure" }.
As a control, use a separate loader that always fails. Two calls continue to report that persistent failure.

Runtime or environment

Verified at commit 8b181716ac with Node v26.10.0 and npm 11.19.1, installed lockfile dependencies, and a simulated device manager.

Expected behavior

Once the adapter loads successfully, its current availability signal should no longer describe the earlier failure. Capability discovery should evaluate the working adapter without obsolete installation-repair guidance. An adapter that still cannot load should continue to report its current failure.

Actual behavior

The probe observed a failed first call and a successful second call, but the availability failure remained transient load failure. Source tracing establishes that the server incorporates this value into its availability policy and the capability inventory returns provider_unavailable for Frida operations. A running MCP server was not exercised.

Evidence

Expected source: AGENTS.md, Performance, requires fresh cached live state; src/server/createServer.ts:214 evaluates current Frida load availability for its policy, and src/application/CapabilityInventory.ts:297 interprets the presence of a failure as provider_unavailable.
Failure source: src/frida/FridaInstrumentationManager.ts:882 retries after a failed load and assigns the successful manager without clearing the stored failure; its accessor at line 125 returns that failure. The focused loader-recovery probe observed successful enumeration with the old failure still present. src/application/CapabilityInventory.ts:326 applies the stale value to Frida operations.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

The focused probe passed its observation assertions, including the persistent-failure control. The manager state was reproduced locally; the inventory consequence is a static trace of the production consumer. Recovery from an actual native-binding failure was not tested.

Restoration check

Repeat the fail-once loader sequence. After the second device-list call succeeds, no load failure should remain in the manager's current availability signal. The capability inventory should no longer report the old failure for Frida operations. Repeat the always-failing-loader control and verify that its current load failure remains reported.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: Capability discovery falsely marks working operations unavailable and recommends repair/restart for the rest of the manager's lifetime. Callers using discovery to choose operations receive a consequential false signal, while the provider itself continues to work.
Workaround status: available
Workaround basis: The focused probe successfully called device discovery despite the stale failure signal, so callers can use the operation directly instead of relying on this availability entry.

Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2528 ## Summary After a Frida adapter load fails once and a subsequent attempt succeeds, device discovery works but the manager still reports the original load failure. Capability discovery reads this obsolete failure and classifies the Frida tools as unavailable, with an instruction to repair the installation and restart. ## Steps to reproduce Use the tested main revision and a fake device manager whose device enumeration succeeds. This reproduction tests adapter loading without opening a native target or remote connection. 1. Construct the Frida instrumentation manager with a loader that throws `Error("transient load failure")` on its first call and returns the fake manager on its second call. 2. Call `listDevices()`. It returns a failed result and the availability failure records the loader error. 3. Call `listDevices()` again. It succeeds and returns the fake device list. 4. Read `availabilityFailure()`. It still returns `{ providerId: "frida", reason: "transient load failure" }`. 5. As a control, use a separate loader that always fails. Two calls continue to report that persistent failure. ## Runtime or environment Verified at commit 8b181716aca2cb467be499cba226abfb5ae19141 with Node v26.10.0 and npm 11.19.1, installed lockfile dependencies, and a simulated device manager. ## Expected behavior Once the adapter loads successfully, its current availability signal should no longer describe the earlier failure. Capability discovery should evaluate the working adapter without obsolete installation-repair guidance. An adapter that still cannot load should continue to report its current failure. ## Actual behavior The probe observed a failed first call and a successful second call, but the availability failure remained `transient load failure`. Source tracing establishes that the server incorporates this value into its availability policy and the capability inventory returns `provider_unavailable` for Frida operations. A running MCP server was not exercised. ## Evidence - Expected source: `AGENTS.md`, Performance, requires fresh cached live state; `src/server/createServer.ts:214` evaluates current Frida load availability for its policy, and `src/application/CapabilityInventory.ts:297` interprets the presence of a failure as provider_unavailable. - Failure source: `src/frida/FridaInstrumentationManager.ts:882` retries after a failed load and assigns the successful manager without clearing the stored failure; its accessor at line 125 returns that failure. The focused loader-recovery probe observed successful enumeration with the old failure still present. `src/application/CapabilityInventory.ts:326` applies the stale value to Frida operations. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete The focused probe passed its observation assertions, including the persistent-failure control. The manager state was reproduced locally; the inventory consequence is a static trace of the production consumer. Recovery from an actual native-binding failure was not tested. ## Restoration check Repeat the fail-once loader sequence. After the second device-list call succeeds, no load failure should remain in the manager's current availability signal. The capability inventory should no longer report the old failure for Frida operations. Repeat the always-failing-loader control and verify that its current load failure remains reported. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: Capability discovery falsely marks working operations unavailable and recommends repair/restart for the rest of the manager's lifetime. Callers using discovery to choose operations receive a consequential false signal, while the provider itself continues to work. - Workaround status: available - Workaround basis: The focused probe successfully called device discovery despite the stale failure signal, so callers can use the operation directly instead of relying on this availability entry.

bsakaguchi

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

closed this issue
added the
area: native

bug
labels

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Addressed on main in 5fa7a52d1f4b28c0b842c5737b84fef6ef2a8eb4.

Optional binding loading is coalesced, and a successful retry clears the current adapter availability failure.

Validation: Affected suites passed in the merged 65-file run (1169 passed, 2 explicit skips), with full static/architecture checks and documentation checks passing. Final installed-package verification is recorded separately in the audit.

Verification scope: Controlled source and production-boundary verification on macOS with pinned Node 24.18.0; real external engines and Windows hosts were not independently rerun. Closure covers the described source defect, not broader provider conformance or performance.

@morluto commented on GitHub (Oct 14, 2026): Addressed on main in [5fa7a52d1f4b28c0b842c5737b84fef6ef2a8eb4](https://github.com/morluto/rea/commit/5fa7a52d1f4b28c0b842c5737b84fef6ef2a8eb4). Optional binding loading is coalesced, and a successful retry clears the current adapter availability failure. Validation: Affected suites passed in the merged 65-file run (1169 passed, 2 explicit skips), with full static/architecture checks and documentation checks passing. Final installed-package verification is recorded separately in the audit. Verification scope: Controlled source and production-boundary verification on macOS with pinned Node 24.18.0; real external engines and Windows hosts were not independently rerun. Closure covers the described source defect, not broader provider conformance or performance.

bsakaguchi referenced this issue

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

[PR #844] [MERGED] fix(firmware): accept the verified Binwalk and Unblob release lines #2281

bsakaguchi referenced this issue

2026-10-17 21:12:14 +00:00

[PR #1540] [MERGED] fix(javascript): accept the Wakaru 1.x release line and verify 1.14.0 #2956