[PR #6387] [CLOSED] fix(frida): report resuming a running session as a session_id error #7328

Closed
opened 2026-11-01 21:47:05 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6387
Author: @bercedev
Created: 10/22/2026
Status: ❌ Closed

Base: main ← Head: fix/frida-resume-state-error


📝 Commits (1)

  • 9815457 fix(frida): report resuming a running session as a session_id error

📊 Changes

3 files changed (+52 additions, -7 deletions)

View changed files

📝 src/application/frida/FridaInstrumentationManager.test.ts (+37 -0)
📝 src/application/frida/fridaInputErrors.ts (+13 -0)
📝 src/frida/FridaInstrumentationManager.ts (+2 -7)

📄 Description

Summary

resume_frida_session on an attached session, or on a spawn that was already resumed, returned capability_unavailable / unsupported_provider with "choose another analysis or target". The real reason (the session has no paused spawn) was only in details.reason. It now returns an invalid_request with a session_id issue that says the session is already running and to skip resume for attached or already-resumed sessions. The refusal itself is unchanged: no native resume call is made.

Fixes #6028

Problem and expected behavior

Trigger: start an attach session, or start a spawn and resume it once, then call resume_frida_session again. The resume contract says it applies to paused spawns and that attached processes are already running, so this is a caller/session-state error, not provider availability.

Change and scope

#resumeSession returns a new notPausedFridaSession input error, next to the existing unknownFridaSession in fridaInputErrors.ts, the same shape the manager already uses for a session ID that names no open session. The cleanup-pending refusal right after it stays capability_unavailable, since that one is about retained scripts.

Follow the contribution scope.

Contract and boundary impact

  • Semantic owner and earliest changed stage: FridaInstrumentationManager.#resumeSession, the session-state check before any native call.
  • Contribution scope fit and linked maintainer decision: ordinary fix, not applicable.
  • CLI and MCP/tool-catalog contract: no schema change; the error for this case moves from capability_unavailable to invalid_request with a session_id issue.
  • Provider, bridge, target-format, or platform compatibility: Frida only.
  • Evidence, artifact, provenance, or reconstruction contract: none.
  • Target selection, authority, upstream behavior, and cleanup details (if applicable): unchanged; the session is still refused and nothing is resumed.
  • Generated metadata (docs/public/product-catalog.json), package, or installation impact: none.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

  • Tests added or updated: FridaInstrumentationManager.test.ts, "refuses to resume a running session as a session_id input error": an attach session and a spawn resumed once both get AnalysisInputError with a session_id / invalid_value issue, and the fake device saw exactly one resume.
  • Base reproduction or other evidence: on main the new test fails with AnalysisCapabilityUnavailableError.
  • User-visible CLI/MCP output (if applicable): not captured; AnalysisInputError projects to invalid_request like the existing unknown-session error.
  • Remaining proof gaps: no real Frida device; native bindings are the existing fakes.

Validation performed

In a Node 24 container with no network, after npm ci:

  • vitest run on FridaInstrumentationManager.test.ts, FridaInstrumentationService.test.ts, tests/boundary/mcp/fridaMcp.test.ts, tests/boundary/mcp/fridaLifecycleMcp.test.ts, tests/boundary/cli/fridaCli.test.ts: 140 passed.
  • node scripts/run-typescript.mjs --noEmit: no errors.
  • oxlint on the changed files: 12 warnings, 0 errors, the same 12 as on main.
  • oxfmt --check on the changed files: clean.
  • npm run verify:module-boundaries: passed.

Compatibility, safety, and release

  • Breaking changes or migration steps: a caller that matched capability_unavailable for this case now gets invalid_request; the refusal is the same.
  • Real Hopper/Ghidra, browser, or OS coverage: none; Frida fakes only.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: no new target interaction; the message only echoes the caller's session ID.

Author readiness

Human owner: @bercedev

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • 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.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • 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/6387 **Author:** [@bercedev](https://github.com/bercedev) **Created:** 10/22/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/frida-resume-state-error` --- ### 📝 Commits (1) - [`9815457`](https://github.com/morluto/rea/commit/9815457fe826843ea518d32c43a6cdadd0e0b4ce) fix(frida): report resuming a running session as a session_id error ### 📊 Changes **3 files changed** (+52 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `src/application/frida/FridaInstrumentationManager.test.ts` (+37 -0) 📝 `src/application/frida/fridaInputErrors.ts` (+13 -0) 📝 `src/frida/FridaInstrumentationManager.ts` (+2 -7) </details> ### 📄 Description ## Summary `resume_frida_session` on an attached session, or on a spawn that was already resumed, returned `capability_unavailable` / `unsupported_provider` with "choose another analysis or target". The real reason (the session has no paused spawn) was only in `details.reason`. It now returns an `invalid_request` with a `session_id` issue that says the session is already running and to skip resume for attached or already-resumed sessions. The refusal itself is unchanged: no native resume call is made. Fixes #6028 ## Problem and expected behavior Trigger: start an attach session, or start a spawn and resume it once, then call `resume_frida_session` again. The resume contract says it applies to paused spawns and that attached processes are already running, so this is a caller/session-state error, not provider availability. ## Change and scope `#resumeSession` returns a new `notPausedFridaSession` input error, next to the existing `unknownFridaSession` in `fridaInputErrors.ts`, the same shape the manager already uses for a session ID that names no open session. The cleanup-pending refusal right after it stays `capability_unavailable`, since that one is about retained scripts. Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). ## Contract and boundary impact - Semantic owner and earliest changed stage: `FridaInstrumentationManager.#resumeSession`, the session-state check before any native call. - Contribution scope fit and linked maintainer decision: ordinary fix, not applicable. - CLI and MCP/tool-catalog contract: no schema change; the error for this case moves from `capability_unavailable` to `invalid_request` with a `session_id` issue. - Provider, bridge, target-format, or platform compatibility: Frida only. - Evidence, artifact, provenance, or reconstruction contract: none. - Target selection, authority, upstream behavior, and cleanup details (if applicable): unchanged; the session is still refused and nothing is resumed. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [ ] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: `FridaInstrumentationManager.test.ts`, "refuses to resume a running session as a session_id input error": an attach session and a spawn resumed once both get `AnalysisInputError` with a `session_id` / `invalid_value` issue, and the fake device saw exactly one resume. - Base reproduction or other evidence: on `main` the new test fails with `AnalysisCapabilityUnavailableError`. - User-visible CLI/MCP output (if applicable): not captured; `AnalysisInputError` projects to `invalid_request` like the existing unknown-session error. - Remaining proof gaps: no real Frida device; native bindings are the existing fakes. ## Validation performed In a Node 24 container with no network, after `npm ci`: - `vitest run` on `FridaInstrumentationManager.test.ts`, `FridaInstrumentationService.test.ts`, `tests/boundary/mcp/fridaMcp.test.ts`, `tests/boundary/mcp/fridaLifecycleMcp.test.ts`, `tests/boundary/cli/fridaCli.test.ts`: 140 passed. - `node scripts/run-typescript.mjs --noEmit`: no errors. - `oxlint` on the changed files: 12 warnings, 0 errors, the same 12 as on `main`. - `oxfmt --check` on the changed files: clean. - `npm run verify:module-boundaries`: passed. ## Compatibility, safety, and release - Breaking changes or migration steps: a caller that matched `capability_unavailable` for this case now gets `invalid_request`; the refusal is the same. - Real Hopper/Ghidra, browser, or OS coverage: none; Frida fakes only. - Package or release metadata impact: none. - Security, privacy, process, or containment review: no new target interaction; the message only echoes the caller's session ID. ## Author readiness Human owner: @bercedev - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [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. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [ ] 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-11-01 21:47:05 +00:00
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#7328
No description provided.