[GH-ISSUE #478] [UX] Make Hopper provider failures diagnosable from MCP #254

New issue

Closed

opened 2026-10-15 18:23:02 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:23:02 +00:00

Owner

Originally created by @morluto on GitHub (Sep 28, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/478

Problem

A Hopper-backed MCP request failed with a generic provider_unavailable message that told me to run rea doctor, but the doctor report did not explain the failure or show a problem with Hopper. That leaves the MCP caller without a useful next step.

Observed behavior

During a macOS arm64 native-binary investigation, several bounded find_code_for_string requests issued together all returned:

Analysis could not start or stopped unexpectedly. Run `rea doctor`, then try again.

Each response marked the error retryable and reported restart_required: false, but gave no request-stage detail, retry guidance, or provider-specific recovery action.

Immediately before the failed requests, binary_session showed an open target, Hopper as the active provider, and no active or queued analysis. Running npx -y rea-agents doctor afterward reported healthy: true and found the Hopper launcher. Its only failed scope check was that optional Ghidra was not configured; no Hopper operation-health result explained the MCP errors.

The underlying failure may have been transient or related to concurrent work; the current response does not expose enough evidence to tell.

Expected behavior

Return the failing stage and provider state when available (for example, launch, connection, analysis, or decompilation), while preserving unknowns when REA cannot determine the cause.
Distinguish a transient/busy provider from a crashed or unreachable provider.
Give an accurate retry instruction, including whether to retry immediately, wait, or restart the owned provider.
Make binary_session or a target-scoped doctor check expose the active provider's operational health, and keep unrelated optional-provider setup findings from obscuring it.
Include a request/correlation identifier so a follow-up diagnostic can be tied to the failed call.

Reproduction

Open a native binary through REA with Hopper selected.
Issue several bounded Hopper-backed MCP analysis requests concurrently.
Observe repeated generic provider_unavailable results.
Run rea doctor; it may report installation/configuration health without identifying the active Hopper request failure.

This is a follow-up to the general Hopper lifecycle diagnostics in #19, provider-neutral error classification in #53, and actionable MCP errors in #261. The remaining gap is correlating an active MCP failure with target/provider health and a concrete recovery path.

Originally created by @morluto on GitHub (Sep 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/478 ## Problem A Hopper-backed MCP request failed with a generic `provider_unavailable` message that told me to run `rea doctor`, but the doctor report did not explain the failure or show a problem with Hopper. That leaves the MCP caller without a useful next step. ## Observed behavior During a macOS arm64 native-binary investigation, several bounded `find_code_for_string` requests issued together all returned: ```text Analysis could not start or stopped unexpectedly. Run `rea doctor`, then try again. ``` Each response marked the error retryable and reported `restart_required: false`, but gave no request-stage detail, retry guidance, or provider-specific recovery action. Immediately before the failed requests, `binary_session` showed an open target, Hopper as the active provider, and no active or queued analysis. Running `npx -y rea-agents doctor` afterward reported `healthy: true` and found the Hopper launcher. Its only failed scope check was that optional Ghidra was not configured; no Hopper operation-health result explained the MCP errors. The underlying failure may have been transient or related to concurrent work; the current response does not expose enough evidence to tell. ## Expected behavior - Return the failing stage and provider state when available (for example, launch, connection, analysis, or decompilation), while preserving unknowns when REA cannot determine the cause. - Distinguish a transient/busy provider from a crashed or unreachable provider. - Give an accurate retry instruction, including whether to retry immediately, wait, or restart the owned provider. - Make `binary_session` or a target-scoped doctor check expose the active provider's operational health, and keep unrelated optional-provider setup findings from obscuring it. - Include a request/correlation identifier so a follow-up diagnostic can be tied to the failed call. ## Reproduction 1. Open a native binary through REA with Hopper selected. 2. Issue several bounded Hopper-backed MCP analysis requests concurrently. 3. Observe repeated generic `provider_unavailable` results. 4. Run `rea doctor`; it may report installation/configuration health without identifying the active Hopper request failure. ## Related work This is a follow-up to the general Hopper lifecycle diagnostics in #19, provider-neutral error classification in #53, and actionable MCP errors in #261. The remaining gap is correlating an active MCP failure with target/provider health and a concrete recovery path.

bsakaguchi

2026-10-15 18:23:02 +00:00

closed this issue
added the
area: mcp

triage

bug
labels

bsakaguchi referenced this issue

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

[GH-ISSUE #2120] [Design] Copyright compliance concerns regarding agent access to original source code #692

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

No description provided.

Rows
Columns