morluto/rea

Fork 0

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

[GH-ISSUE #7557] [Bug] Direct JEB connection failures omit the selected endpoint #4497

New issue

Closed

opened 2026-10-31 00:50:17 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:50:17 +00:00

Owner

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

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 REA_JEB_MCP_URL set to a valid non-default loopback URL, node scripts/rea.mjs inspect-jeb-client --json contacts that URL but returns a typed failure containing no record of it. The selected endpoint is absent from the message, remediation, details, and stderr.

A verifier-owned fixture logged the incoming POST /mcp and returned HTTP 404. The command exited 1 with capability_unavailable, preserving the response text in details.reason, but the only URL in its output was the default endpoint mentioned in generic recovery guidance. The selected URL was also absent in separately executed HTML-response and closed-port controls.

Reproduction

Use the built checkout at the revision below with the repository-pinned Node.js 24.22.1 selected on PATH.
From the checkout root, run this inline fixture. It starts its own loopback listener, gives REA isolated HOME/XDG directories, runs the public CLI, and stops and waits for its owned listener by PID.

python3 - <<'PYTHON'
import json, os, subprocess, tempfile
from pathlib import Path

fixture = '''
const http = require('node:http');
http.createServer((req, res) => {
  console.error(req.method + ' ' + req.url);
  res.writeHead(404, {'content-type': 'text/plain'});
  res.end('not found');
}).listen(0, '127.0.0.1', function () {
  console.log(this.address().port);
});
'''
with tempfile.TemporaryDirectory() as work:
    env = {'PATH': os.environ['PATH']}
    for key in ('HOME', 'XDG_CONFIG_HOME', 'XDG_CACHE_HOME',
                'XDG_DATA_HOME', 'XDG_STATE_HOME'):
        directory = Path(work, key)
        directory.mkdir()
        env[key] = str(directory)
    server = subprocess.Popen(['node', '-e', fixture], env=env,
                              stdout=subprocess.PIPE, stderr=subprocess.PIPE,
                              text=True)
    try:
        port = int(server.stdout.readline())
        endpoint = f'http://127.0.0.1:{port}/mcp'
        run = subprocess.run(
            ['node', 'scripts/rea.mjs', 'inspect-jeb-client', '--json'],
            env={**env, 'REA_JEB_MCP_URL': endpoint,
                 'REA_JEB_MCP_TIMEOUT_MS': '3000'},
            capture_output=True, text=True, timeout=20)
        print(json.dumps({'configured_endpoint': endpoint,
                          'exit_status': run.returncode,
                          'endpoint_retained': endpoint in run.stdout,
                          'result': json.loads(run.stdout)}, indent=2))
    finally:
        server.terminate()
        server.wait(timeout=5)
        print('fixture requests:', server.stderr.read().strip())
PYTHON

Read configured_endpoint, exit_status, endpoint_retained, and the returned error. The fixture logged POST /mcp; the CLI exited 1 and endpoint_retained was false.

The HTTP 404 case reproduced three times in three runs, including one run of this reduced fixture. Additional independent controls reproduced endpoint omission once each with HTTP 200 text/html and with a port whose verifier-owned listener was stopped before the command.

Expected behavior

A direct JEB failure should retain the caller-selected endpoint so the returned diagnostic identifies the service it attempted. The project's caller-input preservation invariant explicitly includes URLs. The JEB guide also describes endpoint retention in Evidence and availability failures with recovery guidance; it does not explicitly prescribe an endpoint field on every transport error.

This report requests retention of the selected URL. The existing availability classification and generic recovery message can remain while that identity is preserved.

Impact and scope

P2: the returned diagnostic loses service identity for the reproduced direct inspection failures, so a saved error alone cannot identify which configured service produced it. The practical workaround demonstrated by the reproduction is to record the selected endpoint alongside the error before invoking REA.

Observed scope is the public CLI with valid non-default IPv4 loopback endpoints, before a JEB client-information reply. The HTTP response reason remains available. No target data, completed analysis result, or security boundary was affected. Successful JEB connections, real-engine behavior, direct MCP projection, discovery projection, timeouts, redirects, proxies, and other JEB operations were not exercised by this verification.

REA version

Exact node scripts/rea.mjs --version output:

6.8.0

Source commit: 65f1c447344a423fa2785847dbcea1e9a9e2454a.

Runtime and platform

Node.js v24.22.1; macOS 27.0.1; arm64. The fixture uses Node's built-in HTTP server; it does not require JEB or launch a GUI.

Target and artifact context

Target-free JEB client inspection. The fixture returns a small authored HTTP response; no binary or project database is involved.

Interface

CLI

Earliest failure stage

Setup or provider admission

Relevant output or evidence

The reduced reproduction selected http://127.0.0.1:59222/mcp; the ephemeral port will vary. Its fixture logged POST /mcp, and the CLI exited 1 with this complete stdout error and empty stderr:

{
  "code": "capability_unavailable",
  "category": "unsupported_provider",
  "message": "Start a JEB client serving MCP (default http://127.0.0.1:8425/mcp) or set REA_JEB_MCP_URL to the running endpoint.",
  "retryable": false,
  "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."
  },
  "details": {
    "provider_id": "jeb",
    "operation": "inspect_jeb_client",
    "reason": "Error POSTing to endpoint: not found"
  }
}

The two other controls returned the same fields with details.reason equal to Unexpected content type: text/html and fetch failed, respectively. Neither retained its configured endpoint.

Contract and source references at the baseline:

AGENTS.md:13 requires retaining caller-selected inputs, explicitly including URLs.
docs/jeb-analysis.md:56 describes endpoint and parameter retention in Evidence; docs/jeb-analysis.md:68 describes unreachable-endpoint availability failures with recovery guidance. Neither sentence independently specifies a transport-error field schema.
src/jeb/JebProvider.ts:178-191 passes the selected endpoint to the connection. src/jeb/JebProvider.ts:242-256 maps execution failures through the provider error path.
src/jeb/JebProvider.ts:576-586 constructs the direct availability failure with a reason and generic recovery message, without endpoint diagnostics. The discovery path separately retains endpoint diagnostics at src/jeb/JebProvider.ts:223-225,229-234.

Typed outcome or recovery expected

Keep a typed failure and its meaningful cause, with the selected endpoint available in the returned diagnostics. For the fixture above, the error should identify the configured non-default URL that received the request. No exact field name or new error code is required by this report.

Analysis or suspected cause

Source-derived explanation: the provider retains the endpoint on its instance and supplies it to the transport, but its direct connection-failure mapping does not attach that value to the error. The observed error confirms the loss through the production CLI boundary. This differs from the endpoint diagnostics explicitly attached by availability discovery.

Additional context

Searched open/closed issues, issue comments, and open/closed/merged pull requests using JEB endpoint, transport, diagnostics, recovery, REA_JEB_MCP_URL, inspect-jeb-client, and missing/omitted endpoint terms.

Related issue #5451 covers discovery recovery guidance; its comments also describe misleading generic advice for reachable HTTP services. That concern is excluded here. Its closure describes adding discovery guidance while preserving discovery diagnostics, rather than restoring endpoint identity in direct CLI failures. This report does not claim a regression of that discovery fix.

Issue #3908 concerns the selected artifact path being replaced by the service endpoint on an engine refusal. This report concerns loss of the service endpoint on a transport failure. Other plausible reports and PRs concerned validation, metadata, cleanup ownership, reconnects, setup registration, or timeout controls; no matching direct-error endpoint-retention report was found.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: All five independently executed direct inspection failures omitted the selected service URL, preventing attribution from the returned error alone; response causes remained available and no target result was lost.
Workaround status: available
Workaround basis: The executed reproduction records the explicitly selected URL alongside the CLI error, retaining service identity without changing REA or weakening a boundary.

Originally created by @coygeek on GitHub (Oct 27, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7557 ### 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 `REA_JEB_MCP_URL` set to a valid non-default loopback URL, `node scripts/rea.mjs inspect-jeb-client --json` contacts that URL but returns a typed failure containing no record of it. The selected endpoint is absent from the message, remediation, details, and stderr. A verifier-owned fixture logged the incoming `POST /mcp` and returned HTTP 404. The command exited 1 with `capability_unavailable`, preserving the response text in `details.reason`, but the only URL in its output was the default endpoint mentioned in generic recovery guidance. The selected URL was also absent in separately executed HTML-response and closed-port controls. ### Reproduction 1. Use the built checkout at the revision below with the repository-pinned Node.js 24.22.1 selected on `PATH`. 2. From the checkout root, run this inline fixture. It starts its own loopback listener, gives REA isolated HOME/XDG directories, runs the public CLI, and stops and waits for its owned listener by PID. ```sh python3 - <<'PYTHON' import json, os, subprocess, tempfile from pathlib import Path fixture = ''' const http = require('node:http'); http.createServer((req, res) => { console.error(req.method + ' ' + req.url); res.writeHead(404, {'content-type': 'text/plain'}); res.end('not found'); }).listen(0, '127.0.0.1', function () { console.log(this.address().port); }); ''' with tempfile.TemporaryDirectory() as work: env = {'PATH': os.environ['PATH']} for key in ('HOME', 'XDG_CONFIG_HOME', 'XDG_CACHE_HOME', 'XDG_DATA_HOME', 'XDG_STATE_HOME'): directory = Path(work, key) directory.mkdir() env[key] = str(directory) server = subprocess.Popen(['node', '-e', fixture], env=env, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True) try: port = int(server.stdout.readline()) endpoint = f'http://127.0.0.1:{port}/mcp' run = subprocess.run( ['node', 'scripts/rea.mjs', 'inspect-jeb-client', '--json'], env={**env, 'REA_JEB_MCP_URL': endpoint, 'REA_JEB_MCP_TIMEOUT_MS': '3000'}, capture_output=True, text=True, timeout=20) print(json.dumps({'configured_endpoint': endpoint, 'exit_status': run.returncode, 'endpoint_retained': endpoint in run.stdout, 'result': json.loads(run.stdout)}, indent=2)) finally: server.terminate() server.wait(timeout=5) print('fixture requests:', server.stderr.read().strip()) PYTHON ``` 3. Read `configured_endpoint`, `exit_status`, `endpoint_retained`, and the returned error. The fixture logged `POST /mcp`; the CLI exited 1 and `endpoint_retained` was false. The HTTP 404 case reproduced three times in three runs, including one run of this reduced fixture. Additional independent controls reproduced endpoint omission once each with HTTP 200 `text/html` and with a port whose verifier-owned listener was stopped before the command. ### Expected behavior A direct JEB failure should retain the caller-selected endpoint so the returned diagnostic identifies the service it attempted. The project's caller-input preservation invariant explicitly includes URLs. The JEB guide also describes endpoint retention in Evidence and availability failures with recovery guidance; it does not explicitly prescribe an endpoint field on every transport error. This report requests retention of the selected URL. The existing availability classification and generic recovery message can remain while that identity is preserved. ### Impact and scope P2: the returned diagnostic loses service identity for the reproduced direct inspection failures, so a saved error alone cannot identify which configured service produced it. The practical workaround demonstrated by the reproduction is to record the selected endpoint alongside the error before invoking REA. Observed scope is the public CLI with valid non-default IPv4 loopback endpoints, before a JEB client-information reply. The HTTP response reason remains available. No target data, completed analysis result, or security boundary was affected. Successful JEB connections, real-engine behavior, direct MCP projection, discovery projection, timeouts, redirects, proxies, and other JEB operations were not exercised by this verification. ### REA version Exact `node scripts/rea.mjs --version` output: ```text 6.8.0 ``` Source commit: `65f1c447344a423fa2785847dbcea1e9a9e2454a`. ### Runtime and platform Node.js `v24.22.1`; macOS `27.0.1`; `arm64`. The fixture uses Node's built-in HTTP server; it does not require JEB or launch a GUI. ### Target and artifact context Target-free JEB client inspection. The fixture returns a small authored HTTP response; no binary or project database is involved. ### Interface CLI ### Earliest failure stage Setup or provider admission ### Relevant output or evidence The reduced reproduction selected `http://127.0.0.1:59222/mcp`; the ephemeral port will vary. Its fixture logged `POST /mcp`, and the CLI exited 1 with this complete stdout error and empty stderr: ```json { "code": "capability_unavailable", "category": "unsupported_provider", "message": "Start a JEB client serving MCP (default http://127.0.0.1:8425/mcp) or set REA_JEB_MCP_URL to the running endpoint.", "retryable": false, "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." }, "details": { "provider_id": "jeb", "operation": "inspect_jeb_client", "reason": "Error POSTing to endpoint: not found" } } ``` The two other controls returned the same fields with `details.reason` equal to `Unexpected content type: text/html` and `fetch failed`, respectively. Neither retained its configured endpoint. Contract and source references at the baseline: - `AGENTS.md:13` requires retaining caller-selected inputs, explicitly including URLs. - `docs/jeb-analysis.md:56` describes endpoint and parameter retention in Evidence; `docs/jeb-analysis.md:68` describes unreachable-endpoint availability failures with recovery guidance. Neither sentence independently specifies a transport-error field schema. - `src/jeb/JebProvider.ts:178-191` passes the selected endpoint to the connection. `src/jeb/JebProvider.ts:242-256` maps execution failures through the provider error path. - `src/jeb/JebProvider.ts:576-586` constructs the direct availability failure with a reason and generic recovery message, without endpoint diagnostics. The discovery path separately retains endpoint diagnostics at `src/jeb/JebProvider.ts:223-225,229-234`. ### Typed outcome or recovery expected Keep a typed failure and its meaningful cause, with the selected endpoint available in the returned diagnostics. For the fixture above, the error should identify the configured non-default URL that received the request. No exact field name or new error code is required by this report. ### Analysis or suspected cause Source-derived explanation: the provider retains the endpoint on its instance and supplies it to the transport, but its direct connection-failure mapping does not attach that value to the error. The observed error confirms the loss through the production CLI boundary. This differs from the endpoint diagnostics explicitly attached by availability discovery. ### Additional context Searched open/closed issues, issue comments, and open/closed/merged pull requests using JEB endpoint, transport, diagnostics, recovery, `REA_JEB_MCP_URL`, `inspect-jeb-client`, and missing/omitted endpoint terms. Related [issue #5451](https://github.com/morluto/rea/issues/5451) covers discovery recovery guidance; its comments also describe misleading generic advice for reachable HTTP services. That concern is excluded here. Its closure describes adding discovery guidance while preserving discovery diagnostics, rather than restoring endpoint identity in direct CLI failures. This report does not claim a regression of that discovery fix. [Issue #3908](https://github.com/morluto/rea/issues/3908) concerns the selected artifact path being replaced by the service endpoint on an engine refusal. This report concerns loss of the service endpoint on a transport failure. Other plausible reports and PRs concerned validation, metadata, cleanup ownership, reconnects, setup registration, or timeout controls; no matching direct-error endpoint-retention report was found. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: All five independently executed direct inspection failures omitted the selected service URL, preventing attribution from the returned error alone; response causes remained available and no target result was lost. - Workaround status: available - Workaround basis: The executed reproduction records the explicitly selected URL alongside the CLI error, retaining service identity without changing REA or weakening a boundary.

bsakaguchi closed this issue

2026-10-31 00:50:17 +00:00

bsakaguchi referenced this issue

2026-10-31 01:13:12 +00:00

[PR #4499] [MERGED] fix(cutter): cancel discovery probes and queued work #6275

bsakaguchi referenced this issue

2026-10-31 01:13:14 +00:00

[PR #4507] [MERGED] fix(cutter): read the active document from core configuration #6276