morluto/rea

Fork 0

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

[GH-ISSUE #8826] [Bug] Objdump discovery remains available after executable launch failure #7766

New issue

Open

opened 2026-11-03 17:35:03 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-11-03 17:35:03 +00:00

Owner

Originally created by @morluto on GitHub (Nov 3, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8826

Before submitting

I searched the open and closed issues and pull requests for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Provider or capability discovery

Observed behavior

binary_session reports inspect_with_objdump as available: true even after that same MCP session observed that the explicitly configured executable cannot be launched.

Reproduction

On the REA 1.990 validation branch, configure REA_OBJDUMP_COMMAND to a nonexistent absolute path and start a target-free stdio MCP session. binary_session({}) groups inspect_with_objdump under available: true, reason: available. Calling inspect_with_objdump({operation: "architectures"}) returns capability_unavailable, with provider-launch / ENOENT diagnostics. A second binary_session({}) on the same connection still reports the tool available. I observed this in separate compact and full sessions; no target was opened. The same result occurred on #8824 head 35fc4aff0.

Expected behavior

Distinguish a registered operation from a selected executable whose readiness is unknown or whose launch has already failed, without blocking a later retry or inferring that every objdump installation is absent. The exact availability and recovery model needs design. docs/mcp-contracts.md describes tool availability as helping choose callable operations, while its observed-health section specifically refers to active provider clients; this standalone command's intended health scope should be clarified.

Impact and scope

An agent using discovery can be told to select an operation that has just returned a concrete launch failure. The direct tool error is actionable and retains the configured path; no data was lost. This is a single missing-executable control on one host, not evidence about all standalone providers or dynamic recovery.

REA version

187f3d8ccdf847d759e235c09c034e12bd83bbf2 and #8824 head 35fc4aff0.

Runtime and platform

Node 24.22.1; macOS arm64.

Target and artifact context

Target-free architecture query; no target execution or mutation.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Before and after the failed query: inspect_with_objdump group has available: true, reason: available, remediation: null. The query returns capability_unavailable, details.diagnostics.boundary: provider-launch, system_code: ENOENT.

Typed outcome or recovery expected

Availability should not present a known failing configured executable as established callable; retain a typed reason and allow explicit retry after repair. How to model unprobed executables and revalidate a changed path is open.

Analysis or suspected cause

Source-derived: BinarySession gets operation-health data from the active analysis client; standalone objdump commands use a separate reverse-engineering service. Whether and where to own their readiness and freshness needs investigation; do not treat static registration as proof a process can launch.

Additional context

Related #8823 / #8824 concerns executable identity, not readiness. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Same-connection repair control

On the same validation branch and macOS arm64, each fresh compact/full MCP session was configured with a different nonexistent path in a disposable directory. binary_session reported the objdump operation available, its explicit disassembly failed with capability_unavailable, and discovery still reported available. I then created a symlink at the selected path to a temporary GNU objdump 2.47 executable and repeated the identical call in the same session: symbol-scoped disassembly of a self-built x86-64 ELF object succeeded with child exit 0, and discovery continued to report available. The ELF SHA-256 d5cd9178915e560a40cfd707180dad0536fe5050cbc8f323482852a1c4d34a36 remained unchanged. This verifies a working direct retry after this specific executable repair; it does not establish that availability was probed or that other launch failures recover the same way.

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8826 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Provider or capability discovery ### Observed behavior `binary_session` reports `inspect_with_objdump` as `available: true` even after that same MCP session observed that the explicitly configured executable cannot be launched. ### Reproduction On the REA 1.990 validation branch, configure `REA_OBJDUMP_COMMAND` to a nonexistent absolute path and start a target-free stdio MCP session. `binary_session({})` groups `inspect_with_objdump` under `available: true`, `reason: available`. Calling `inspect_with_objdump({operation: "architectures"})` returns `capability_unavailable`, with `provider-launch` / `ENOENT` diagnostics. A second `binary_session({})` on the same connection still reports the tool available. I observed this in separate compact and full sessions; no target was opened. The same result occurred on #8824 head `35fc4aff0`. ### Expected behavior Distinguish a registered operation from a selected executable whose readiness is unknown or whose launch has already failed, without blocking a later retry or inferring that every objdump installation is absent. The exact availability and recovery model needs design. `docs/mcp-contracts.md` describes tool availability as helping choose callable operations, while its observed-health section specifically refers to active provider clients; this standalone command's intended health scope should be clarified. ### Impact and scope An agent using discovery can be told to select an operation that has just returned a concrete launch failure. The direct tool error is actionable and retains the configured path; no data was lost. This is a single missing-executable control on one host, not evidence about all standalone providers or dynamic recovery. ### REA version `187f3d8ccdf847d759e235c09c034e12bd83bbf2` and #8824 head `35fc4aff0`. ### Runtime and platform Node 24.22.1; macOS arm64. ### Target and artifact context Target-free architecture query; no target execution or mutation. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence Before and after the failed query: `inspect_with_objdump` group has `available: true`, `reason: available`, `remediation: null`. The query returns `capability_unavailable`, `details.diagnostics.boundary: provider-launch`, `system_code: ENOENT`. ### Typed outcome or recovery expected Availability should not present a known failing configured executable as established callable; retain a typed reason and allow explicit retry after repair. How to model unprobed executables and revalidate a changed path is open. ### Analysis or suspected cause Source-derived: `BinarySession` gets operation-health data from the active analysis client; standalone objdump commands use a separate reverse-engineering service. Whether and where to own their readiness and freshness needs investigation; do not treat static registration as proof a process can launch. ### Additional context Related #8823 / #8824 concerns executable identity, not readiness. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Same-connection repair control On the same validation branch and macOS arm64, each fresh compact/full MCP session was configured with a different nonexistent path in a disposable directory. `binary_session` reported the objdump operation available, its explicit disassembly failed with `capability_unavailable`, and discovery still reported available. I then created a symlink at the selected path to a temporary GNU objdump 2.47 executable and repeated the identical call in the same session: symbol-scoped disassembly of a self-built x86-64 ELF object succeeded with child exit 0, and discovery continued to report available. The ELF SHA-256 `d5cd9178915e560a40cfd707180dad0536fe5050cbc8f323482852a1c4d34a36` remained unchanged. This verifies a working direct retry after this specific executable repair; it does not establish that availability was probed or that other launch failures recover the same way.

bsakaguchi commented

2026-11-04 03:55:07 +00:00

Author

Owner

@ducanhnguyen223 commented on GitHub (Nov 4, 2026):

I traced the current main path (c3647ade): reverseEngineering is composed separately, while binary_session applies the BinarySession runtime-unavailability map and active-provider health. That explains why a standalone objdump launch failure is not reflected in discovery.

One candidate contract is observation-only: discovery does not launch/probe objdump; an unprobed executable is not claimed as verified; after a provider-launch failure, expose that observation for the selected command in this server session, but keep the explicit operation callable; clear only that observation after a later successful call. This fits the same-connection repair control and the existing active-provider rule that a later dispatched success can recover an observed failure.

The open question is how to represent the unprobed state without implying either success or permanent unavailability. Would you prefer an explicit unknown/readiness state in the output contract, or should the current optimistic availability remain until the first failure? If the observation-and-retry model fits, I can implement it on this issue. I have not changed code while that contract is unresolved.

@ducanhnguyen223 commented on GitHub (Nov 4, 2026): I traced the current `main` path (`c3647ade`): `reverseEngineering` is composed separately, while `binary_session` applies the `BinarySession` runtime-unavailability map and active-provider health. That explains why a standalone objdump launch failure is not reflected in discovery. One candidate contract is observation-only: discovery does not launch/probe objdump; an unprobed executable is not claimed as verified; after a `provider-launch` failure, expose that observation for the selected command in this server session, but keep the explicit operation callable; clear only that observation after a later successful call. This fits the same-connection repair control and the existing active-provider rule that a later dispatched success can recover an observed failure. The open question is how to represent the unprobed state without implying either success or permanent unavailability. Would you prefer an explicit unknown/readiness state in the output contract, or should the current optimistic availability remain until the first failure? If the observation-and-retry model fits, I can implement it on this issue. I have not changed code while that contract is unresolved.

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

No description provided.

Rows
Columns