[GH-ISSUE #2527] fix(frida): remote option conflicts return a provider capability error #846

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

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

Summary

When a remote Frida session remains open, a second request for the same endpoint with different connection options fails with a provider capability error. The manager recognizes the conflict as invalid caller input but discards that classification before returning it, leaving the caller without useful correction guidance.

Steps to reproduce

Use the tested main revision with a fake Frida device manager whose remote-device creation, process lookup, and attach calls succeed. No real target or network connection is needed for this adapter-level reproduction.

  1. Start an attach session for PID 512 with remote address 127.0.0.1:27042 and a nonempty synthetic token one. Keep this session open.
  2. Start another attach session for the same PID and address, changing only the synthetic token to two.
  3. Inspect the failed result's error tag and reason. Repeat the changed-options request through device listing and process listing.
  4. As a control, start another session with the original options. This call succeeds.

Runtime or environment

Verified at commit 8b181716ac with Node v26.10.0 and npm 11.19.1, using the installed lockfile dependencies and fake Frida provider handles.

Expected behavior

A conflict between caller-selected connection options should remain an invalid-input failure. The returned error should explain that the endpoint is already retained with incompatible options and give secret-safe guidance for correcting the request.

Actual behavior

All three changed-options requests returned AnalysisCapabilityUnavailableError with reason Invalid analysis input for frida_remote_connection. The attach error message was Provider frida cannot execute start_frida_session: Invalid analysis input for frida_remote_connection. The result contains no argument issues, while the matching-options control succeeds.

Evidence

  • Expected source: AGENTS.md, Architecture and Cleanup, requires tagged expected failures and meaningful reasons; src/domain/analysisErrorProjection.ts:196 assigns invalid_request to input errors, and src/application/frida/fridaInputErrors.ts:4 shows argument-specific correction metadata. The remote input schema at src/contracts/fridaToolContracts.ts:11 accepts the fixture values.
  • Failure source: src/frida/FridaInstrumentationManager.ts:920 recognizes incompatible retained options as an input error; operation catches at lines 174, 228, and 316 route it to providerError at line 1221, which returns a capability error. The focused fake-provider probe observed that tag for all three operations and successful matching-options startup.
  • Evidence provenance: observed
  • Local verification: reproduced
  • Reproduction completeness: complete

The focused test passed its observation assertions for the conflict and control. The probe tests adapter behavior with simulated provider handles; real-provider coverage was not run.

Restoration check

Keep the first remote session open and repeat the changed-options attach, device-list, and process-list requests. Each should return an invalid-input failure with useful secret-safe correction guidance. Matching connection options should continue to succeed and reuse the retained endpoint. A genuine remote-provider failure should retain its provider failure classification.

Triage assessment

  • Impact level: P2
  • Assessment status: supported
  • Impact basis: Inconsistent options for an already retained endpoint receive the wrong failure category and no actionable explanation, which misdirects caller recovery. The conflict is safely rejected and successful sessions remain usable.
  • Workaround status: available
  • Workaround basis: Reusing the original options succeeded in the focused control. A caller can keep the existing session and use those options without changing its target or credentials.
Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2527 ## Summary When a remote Frida session remains open, a second request for the same endpoint with different connection options fails with a provider capability error. The manager recognizes the conflict as invalid caller input but discards that classification before returning it, leaving the caller without useful correction guidance. ## Steps to reproduce Use the tested main revision with a fake Frida device manager whose remote-device creation, process lookup, and attach calls succeed. No real target or network connection is needed for this adapter-level reproduction. 1. Start an attach session for PID 512 with remote address `127.0.0.1:27042` and a nonempty synthetic token `one`. Keep this session open. 2. Start another attach session for the same PID and address, changing only the synthetic token to `two`. 3. Inspect the failed result's error tag and reason. Repeat the changed-options request through device listing and process listing. 4. As a control, start another session with the original options. This call succeeds. ## Runtime or environment Verified at commit 8b181716aca2cb467be499cba226abfb5ae19141 with Node v26.10.0 and npm 11.19.1, using the installed lockfile dependencies and fake Frida provider handles. ## Expected behavior A conflict between caller-selected connection options should remain an invalid-input failure. The returned error should explain that the endpoint is already retained with incompatible options and give secret-safe guidance for correcting the request. ## Actual behavior All three changed-options requests returned `AnalysisCapabilityUnavailableError` with reason `Invalid analysis input for frida_remote_connection`. The attach error message was `Provider frida cannot execute start_frida_session: Invalid analysis input for frida_remote_connection`. The result contains no argument issues, while the matching-options control succeeds. ## Evidence - Expected source: `AGENTS.md`, Architecture and Cleanup, requires tagged expected failures and meaningful reasons; `src/domain/analysisErrorProjection.ts:196` assigns invalid_request to input errors, and `src/application/frida/fridaInputErrors.ts:4` shows argument-specific correction metadata. The remote input schema at `src/contracts/fridaToolContracts.ts:11` accepts the fixture values. - Failure source: `src/frida/FridaInstrumentationManager.ts:920` recognizes incompatible retained options as an input error; operation catches at lines 174, 228, and 316 route it to `providerError` at line 1221, which returns a capability error. The focused fake-provider probe observed that tag for all three operations and successful matching-options startup. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete The focused test passed its observation assertions for the conflict and control. The probe tests adapter behavior with simulated provider handles; real-provider coverage was not run. ## Restoration check Keep the first remote session open and repeat the changed-options attach, device-list, and process-list requests. Each should return an invalid-input failure with useful secret-safe correction guidance. Matching connection options should continue to succeed and reuse the retained endpoint. A genuine remote-provider failure should retain its provider failure classification. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: Inconsistent options for an already retained endpoint receive the wrong failure category and no actionable explanation, which misdirects caller recovery. The conflict is safely rejected and successful sessions remain usable. - Workaround status: available - Workaround basis: Reusing the original options succeeded in the focused control. A caller can keep the existing session and use those options without changing its target or credentials.
bsakaguchi 2026-10-15 18:28:56 +00:00
Author
Owner

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

Addressed on main in 5fa7a52d1f4b28c0b842c5737b84fef6ef2a8eb4.

Conflicting retained remote connection options return AnalysisInputError with an actionable issue, preserving the input-error contract.

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.

<!-- gh-comment-id:6159185910 --> @morluto commented on GitHub (Oct 14, 2026): Addressed on main in [5fa7a52d1f4b28c0b842c5737b84fef6ef2a8eb4](https://github.com/morluto/rea/commit/5fa7a52d1f4b28c0b842c5737b84fef6ef2a8eb4). Conflicting retained remote connection options return AnalysisInputError with an actionable issue, preserving the input-error contract. 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.
Sign in to join this conversation.
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#846
No description provided.