morluto/rea

Fork 0

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

[GH-ISSUE #5451] [Bug] JEB discovery omits recovery guidance when the configured endpoint is unreachable #3311

New issue

Closed

opened 2026-10-31 00:39:03 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:39:03 +00:00

Owner

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

Before submitting

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

Area

Provider or capability discovery

Observed behavior

With a valid configured loopback JEB MCP URL that has no listener, target-free binary_session {} marks all four JEB tools unavailable but gives only JEB MCP catalog failed as their remediation. Direct MCP inspect_jeb_client {} and CLI inspection in the same environment return actionable instructions to start the service or configure its endpoint.

Reproduction

The independent verifier executed these steps against the built source revision below, with isolated HOME/XDG directories:

Set REA_JEB_MCP_URL=http://127.0.0.1:56661/mcp, where a loopback fixture had allocated and then closed the port before REA connected. Use another unused loopback port if occupied.
Connect an MCP client to node scripts/rea.mjs --mcp and send:

{"method":"tools/call","params":{"name":"binary_session","arguments":{}}}

Read the groups with surface: "jeb-provider" in structuredContent.result.tool_availability.groups.
Over the same MCP connection, call inspect_jeb_client with {}. Also run node scripts/rea.mjs inspect-jeb-client --json with the same endpoint configuration.

Production stdio MCP reproduced the discovery result once; a separate production-handler MCP test also reproduced it once. Both direct inspection interfaces supplied recovery guidance, and the CLI exited 1. No target or JEB installation was required.

Expected behavior

Unavailable JEB discovery entries should contain an actionable recovery step, such as starting the caller-owned JEB MCP service or pointing REA_JEB_MCP_URL at its running endpoint. Exact wording need not match the CLI.

At the tested revision, docs/jeb-analysis.md:28-32,66 documents live discovery and recovery guidance for unreachable endpoints. docs/mcp-contracts.md:424-435,450-453 directs callers to choose operations from the grouped availability inventory and retain remediation inline.

Impact and scope

The documented discovery workflow loses the recovery action for all four JEB tools in the reproduced unreachable configured-endpoint case. Impact is bounded (P2); direct MCP inspection and CLI inspection provide verified workarounds. No analysis result, target data, or security boundary was affected. The default endpoint and successful real-engine behavior were not exercised.

REA version

rea-agents 6.7.0; source commit 074768901f3cdc8205b61773fb1faf6f6c7b3ca8.

Runtime and platform

Node.js v26.12.0; macOS (Darwin), arm64. No JEB engine installation was used.

Target and artifact context

Target-free discovery; no binary, project database, or analysis artifact was opened. The endpoint was an unused loopback URL.

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Production stdio MCP returned these JEB groups, trimmed to relevant fields:

[
  {
    "names": ["decompile_jeb_item", "inspect_jeb_client", "list_jeb_units"],
    "available": false,
    "reason": "provider_missing",
    "remediation": "JEB MCP catalog failed"
  },
  {
    "names": ["open_jeb_project"],
    "available": false,
    "reason": "provider_missing",
    "remediation": "JEB MCP catalog failed"
  }
]

Direct MCP inspection returned capability_unavailable; CLI inspection exited 1 with the same code. Both supplied this remediation action:

Start a JEB client serving MCP (default http://127.0.0.1:8425/mcp) or set REA_JEB_MCP_URL to the running endpoint.

Typed outcome or recovery expected

Keep all four tools in discovery and report them unavailable with an actionable start/configuration instruction. Direct MCP/CLI inspection should continue returning typed provider-availability errors with recovery guidance.

Analysis or suspected cause

Source-derived reasoning at the tested revision: src/jeb/JebMcpConnectionOwner.ts:10-18 creates the catalog failure message; src/jeb/JebProvider.ts:140-174 uses the caught message as the availability reason. src/application/CapabilityInventory.ts:552-566,592-608 then uses that reason as remediation, replacing the actionable fallback. Direct-operation recovery guidance is supplied separately in src/jeb/JebProvider.ts:458-473.

Additional context

Prepared with AI assistance and independently reproduced through production stdio MCP, production MCP handlers, and the built CLI. The submitter checked current upstream source: the relevant implementation files are unchanged from the tested baseline at origin/main commit 052956af3416fa01d93837e54fdec3ad2739f6d1; the intervening change to the cited MCP guide only adds unrelated documentation.

Related #3069 concerned discovery failing to probe a running JEB endpoint and is already fixed. This report concerns recovery guidance after a live probe fails. Searches of open/closed issues and PRs using inspect_jeb_client, JEB recovery, CapabilityInventory JEB, JEB remediation, and the exact catalog failure message found no matching report.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5451 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Provider or capability discovery ### Observed behavior With a valid configured loopback JEB MCP URL that has no listener, target-free `binary_session {}` marks all four JEB tools unavailable but gives only `JEB MCP catalog failed` as their remediation. Direct MCP `inspect_jeb_client {}` and CLI inspection in the same environment return actionable instructions to start the service or configure its endpoint. ### Reproduction The independent verifier executed these steps against the built source revision below, with isolated HOME/XDG directories: 1. Set `REA_JEB_MCP_URL=http://127.0.0.1:56661/mcp`, where a loopback fixture had allocated and then closed the port before REA connected. Use another unused loopback port if occupied. 2. Connect an MCP client to `node scripts/rea.mjs --mcp` and send: ```json {"method":"tools/call","params":{"name":"binary_session","arguments":{}}} ``` 3. Read the groups with `surface: "jeb-provider"` in `structuredContent.result.tool_availability.groups`. 4. Over the same MCP connection, call `inspect_jeb_client` with `{}`. Also run `node scripts/rea.mjs inspect-jeb-client --json` with the same endpoint configuration. Production stdio MCP reproduced the discovery result once; a separate production-handler MCP test also reproduced it once. Both direct inspection interfaces supplied recovery guidance, and the CLI exited 1. No target or JEB installation was required. ### Expected behavior Unavailable JEB discovery entries should contain an actionable recovery step, such as starting the caller-owned JEB MCP service or pointing `REA_JEB_MCP_URL` at its running endpoint. Exact wording need not match the CLI. At the tested revision, `docs/jeb-analysis.md:28-32,66` documents live discovery and recovery guidance for unreachable endpoints. `docs/mcp-contracts.md:424-435,450-453` directs callers to choose operations from the grouped availability inventory and retain remediation inline. ### Impact and scope The documented discovery workflow loses the recovery action for all four JEB tools in the reproduced unreachable configured-endpoint case. Impact is bounded (P2); direct MCP inspection and CLI inspection provide verified workarounds. No analysis result, target data, or security boundary was affected. The default endpoint and successful real-engine behavior were not exercised. ### REA version `rea-agents` 6.7.0; source commit `074768901f3cdc8205b61773fb1faf6f6c7b3ca8`. ### Runtime and platform Node.js v26.12.0; macOS (Darwin), arm64. No JEB engine installation was used. ### Target and artifact context Target-free discovery; no binary, project database, or analysis artifact was opened. The endpoint was an unused loopback URL. ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Production stdio MCP returned these JEB groups, trimmed to relevant fields: ```json [ { "names": ["decompile_jeb_item", "inspect_jeb_client", "list_jeb_units"], "available": false, "reason": "provider_missing", "remediation": "JEB MCP catalog failed" }, { "names": ["open_jeb_project"], "available": false, "reason": "provider_missing", "remediation": "JEB MCP catalog failed" } ] ``` Direct MCP inspection returned `capability_unavailable`; CLI inspection exited 1 with the same code. Both supplied this remediation action: ```text Start a JEB client serving MCP (default http://127.0.0.1:8425/mcp) or set REA_JEB_MCP_URL to the running endpoint. ``` ### Typed outcome or recovery expected Keep all four tools in discovery and report them unavailable with an actionable start/configuration instruction. Direct MCP/CLI inspection should continue returning typed provider-availability errors with recovery guidance. ### Analysis or suspected cause Source-derived reasoning at the tested revision: `src/jeb/JebMcpConnectionOwner.ts:10-18` creates the catalog failure message; `src/jeb/JebProvider.ts:140-174` uses the caught message as the availability reason. `src/application/CapabilityInventory.ts:552-566,592-608` then uses that reason as remediation, replacing the actionable fallback. Direct-operation recovery guidance is supplied separately in `src/jeb/JebProvider.ts:458-473`. ### Additional context Prepared with AI assistance and independently reproduced through production stdio MCP, production MCP handlers, and the built CLI. The submitter checked current upstream source: the relevant implementation files are unchanged from the tested baseline at `origin/main` commit `052956af3416fa01d93837e54fdec3ad2739f6d1`; the intervening change to the cited MCP guide only adds unrelated documentation. Related #3069 concerned discovery failing to probe a running JEB endpoint and is already fixed. This report concerns recovery guidance after a live probe fails. Searches of open/closed issues and PRs using `inspect_jeb_client`, `JEB recovery`, `CapabilityInventory JEB`, `JEB remediation`, and the exact catalog failure message found no matching report.

bsakaguchi closed this issue

2026-10-31 00:39:03 +00:00

bsakaguchi commented

2026-10-31 00:39:03 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 20, 2026):

Additional verified trigger: a reachable configured endpoint returning HTTP 500, HTTP 401, or malformed JSON also produces missing-client recovery advice. This extends the same failure-classification/recovery problem; direct inspection is only a partial workaround for these cases.

Reproduced with rea-agents 6.7.0 on current main at ccc7da309d7db385d5c6d73b0a3a8e093be33504 (Node.js v26.12.0, macOS 27.0.1 arm64), after rebuilding. Tested all three responses both during initialize and during tools/list after a valid handshake, through the built CLI and production stdio MCP (binary_session {} then inspect_jeb_client {}). The fixture logged accepted POSTs; catalog-stage cases logged initialize, notifications/initialized, and tools/list.

All six reachable cases returned:

CLI exit 1 and MCP inspection isError: true, with capability_unavailable / unsupported_provider.
Both discovery groups, covering all four JEB operations, unavailable with reason: provider_missing and remediation: JEB MCP catalog failed.
Direct message/remediation: Start a JEB client serving MCP (default http://127.0.0.1:8425/mcp) or set REA_JEB_MCP_URL to the running endpoint.

Direct details.reason does retain the fixture response body or JSON parser error, so it remains useful diagnostically. The observed SDK error does not separately preserve the numeric HTTP status.

Minimal reproduction of the HTTP 500 initialization case, run from a built source checkout; no JEB engine or target is required:

python3 - <<'PYTHON'
import json, os, subprocess, tempfile, threading
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from pathlib import Path
class Handler(BaseHTTPRequestHandler):
    def log_message(self, *args): pass
    def do_GET(self):
        self.send_response(405); self.end_headers()
    def do_POST(self):
        self.rfile.read(int(self.headers.get('Content-Length', '0')))
        body = b'{"error":"fixture-500"}'
        self.send_response(500)
        self.send_header('Content-Type', 'application/json')
        self.send_header('Content-Length', str(len(body)))
        self.end_headers(); self.wfile.write(body)
server = ThreadingHTTPServer(('127.0.0.1', 0), Handler)
worker = threading.Thread(target=server.serve_forever, daemon=True)
worker.start()
try:
    with tempfile.TemporaryDirectory() as work:
        env = {'PATH': os.environ['PATH'], 'REA_LOG_LEVEL': 'silent',
               'REA_JEB_MCP_URL': f'http://127.0.0.1:{server.server_port}/mcp'}
        for key in ('HOME', 'XDG_CONFIG_HOME', 'XDG_DATA_HOME',
                    'XDG_CACHE_HOME', 'XDG_STATE_HOME', 'TMPDIR'):
            path = Path(work, key); path.mkdir(); env[key] = str(path)
        run = subprocess.run(['node', 'scripts/rea.mjs', 'inspect-jeb-client', '--json'],
                             env=env, capture_output=True, text=True, timeout=40)
        error = json.loads(run.stdout)
        print(json.dumps({'exit': run.returncode, 'code': error['code'],
                          'reason': error['details']['reason'],
                          'action': error['remediation']['action']}, indent=2))
finally:
    server.shutdown(); server.server_close(); worker.join()
PYTHON

Observed output includes exit: 1, code: capability_unavailable, reason: Error POSTing to endpoint: {"error":"fixture-500"}, and the start-client/change-URL action above. The listener runs in the foreground probe's process and is closed and joined in finally.

Expected recovery should distinguish response/protocol failures at an accepted endpoint from an unused endpoint, retain the meaningful cause in discovery as well as direct diagnostics, and keep the operations unavailable. Simply copying today's direct advice into discovery would still misdirect these reachable cases. The closed-port control also reproduced, with details.reason: fetch failed; useful start/configuration guidance should remain for that case. This follows the meaningful-failure preservation contract in AGENTS.md and inline reason/remediation contract in docs/mcp-contracts.md; exact wording or a replacement enum is an implementation choice.

P2, bounded to failure classification and recovery guidance; the retained direct diagnostic provides a workaround for identifying the cause. Source-derived reasoning: the shared catalog wrapper in src/jeb/JebMcpConnectionOwner.ts and unavailable mapping/direct fallback in src/jeb/JebProvider.ts feed the discovery projection in src/application/CapabilityInventory.ts. This fixture establishes response handling, not real-engine authentication support or successful JEB analysis. Prepared with AI assistance and independently reproduced.

@coygeek commented on GitHub (Oct 20, 2026): Additional verified trigger: a **reachable configured endpoint** returning HTTP 500, HTTP 401, or malformed JSON also produces missing-client recovery advice. This extends the same failure-classification/recovery problem; direct inspection is only a partial workaround for these cases. Reproduced with `rea-agents` 6.7.0 on current `main` at `ccc7da309d7db385d5c6d73b0a3a8e093be33504` (Node.js v26.12.0, macOS 27.0.1 arm64), after rebuilding. Tested all three responses both during `initialize` and during `tools/list` after a valid handshake, through the built CLI and production stdio MCP (`binary_session {}` then `inspect_jeb_client {}`). The fixture logged accepted POSTs; catalog-stage cases logged `initialize`, `notifications/initialized`, and `tools/list`. All six reachable cases returned: - CLI exit 1 and MCP inspection `isError: true`, with `capability_unavailable` / `unsupported_provider`. - Both discovery groups, covering all four JEB operations, unavailable with `reason: provider_missing` and `remediation: JEB MCP catalog failed`. - Direct message/remediation: `Start a JEB client serving MCP (default http://127.0.0.1:8425/mcp) or set REA_JEB_MCP_URL to the running endpoint.` Direct `details.reason` does retain the fixture response body or JSON parser error, so it remains useful diagnostically. The observed SDK error does not separately preserve the numeric HTTP status. Minimal reproduction of the HTTP 500 initialization case, run from a built source checkout; no JEB engine or target is required: ```sh python3 - <<'PYTHON' import json, os, subprocess, tempfile, threading from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer from pathlib import Path class Handler(BaseHTTPRequestHandler): def log_message(self, *args): pass def do_GET(self): self.send_response(405); self.end_headers() def do_POST(self): self.rfile.read(int(self.headers.get('Content-Length', '0'))) body = b'{"error":"fixture-500"}' self.send_response(500) self.send_header('Content-Type', 'application/json') self.send_header('Content-Length', str(len(body))) self.end_headers(); self.wfile.write(body) server = ThreadingHTTPServer(('127.0.0.1', 0), Handler) worker = threading.Thread(target=server.serve_forever, daemon=True) worker.start() try: with tempfile.TemporaryDirectory() as work: env = {'PATH': os.environ['PATH'], 'REA_LOG_LEVEL': 'silent', 'REA_JEB_MCP_URL': f'http://127.0.0.1:{server.server_port}/mcp'} for key in ('HOME', 'XDG_CONFIG_HOME', 'XDG_DATA_HOME', 'XDG_CACHE_HOME', 'XDG_STATE_HOME', 'TMPDIR'): path = Path(work, key); path.mkdir(); env[key] = str(path) run = subprocess.run(['node', 'scripts/rea.mjs', 'inspect-jeb-client', '--json'], env=env, capture_output=True, text=True, timeout=40) error = json.loads(run.stdout) print(json.dumps({'exit': run.returncode, 'code': error['code'], 'reason': error['details']['reason'], 'action': error['remediation']['action']}, indent=2)) finally: server.shutdown(); server.server_close(); worker.join() PYTHON ``` Observed output includes `exit: 1`, `code: capability_unavailable`, `reason: Error POSTing to endpoint: {"error":"fixture-500"}`, and the start-client/change-URL action above. The listener runs in the foreground probe's process and is closed and joined in `finally`. Expected recovery should distinguish response/protocol failures at an accepted endpoint from an unused endpoint, retain the meaningful cause in discovery as well as direct diagnostics, and keep the operations unavailable. Simply copying today's direct advice into discovery would still misdirect these reachable cases. The closed-port control also reproduced, with `details.reason: fetch failed`; useful start/configuration guidance should remain for that case. This follows the meaningful-failure preservation contract in `AGENTS.md` and inline reason/remediation contract in `docs/mcp-contracts.md`; exact wording or a replacement enum is an implementation choice. P2, bounded to failure classification and recovery guidance; the retained direct diagnostic provides a workaround for identifying the cause. Source-derived reasoning: the shared catalog wrapper in `src/jeb/JebMcpConnectionOwner.ts` and unavailable mapping/direct fallback in `src/jeb/JebProvider.ts` feed the discovery projection in `src/application/CapabilityInventory.ts`. This fixture establishes response handling, not real-engine authentication support or successful JEB analysis. Prepared with AI assistance and independently reproduced.

bsakaguchi commented

2026-10-31 00:39:03 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 24, 2026):

Checked the reported fix on main at d87e73f2db.

inspectAvailability now appends the same JEB_CONNECTION_REMEDIATION to discovery failure reason, which capability inventory uses as remediation. It names starting a JEB client serving MCP and configuring REA_JEB_MCP_URL, preserving endpoint diagnostics. The unreachable endpoint provider test explicitly checks both recovery strings.

Implementation: JebProvider.ts, JebProvider.test.ts.

The relevant regression checks in JebProvider.test.ts passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

@coygeek commented on GitHub (Oct 24, 2026): Checked the reported fix on `main` at d87e73f2db50be72d33a4b3c7199af35518b441c. inspectAvailability now appends the same JEB_CONNECTION_REMEDIATION to discovery failure reason, which capability inventory uses as remediation. It names starting a JEB client serving MCP and configuring REA_JEB_MCP_URL, preserving endpoint diagnostics. The unreachable endpoint provider test explicitly checks both recovery strings. Implementation: [JebProvider.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/jeb/JebProvider.ts#L173), [JebProvider.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/jeb/JebProvider.test.ts#L152). The relevant regression checks in [JebProvider.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/jeb/JebProvider.test.ts) passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

bsakaguchi referenced this issue

2026-10-31 01:10:44 +00:00

[PR #3898] [MERGED] fix(javascript): retain standalone GraphQL source operations #5956

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

No description provided.

Rows
Columns