morluto/rea

Fork 0

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

[GH-ISSUE #5455] [Bug] environment-serve suggests changing ports for host lookup failures #3313

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

CLI

Observed behavior

environment-serve correctly reports getaddrinfo ENOTFOUND for an unresolvable listener host, but remediation.action tells the caller to change the port or stop its owner. Independent verification reproduced the same advice with two explicit ports and the ephemeral default. Correcting the host started the same manifest.

Reproduction

The following public CLI sequence was independently executed against the built source checkout. The fixture is synthetic; its recorded URL is never fetched.

case_dir="$(mktemp -d)"
mkdir -p "$case_dir/home" "$case_dir/config" "$case_dir/data" "$case_dir/cache" "$case_dir/state"
export HOME="$case_dir/home"
export XDG_CONFIG_HOME="$case_dir/config" XDG_DATA_HOME="$case_dir/data"
export XDG_CACHE_HOME="$case_dir/cache" XDG_STATE_HOME="$case_dir/state"
unset MCP_HOST MCP_PORT ENVIRONMENT_NAME
rea() { node scripts/rea.mjs "$@"; }
cat > "$case_dir/session.har" <<'JSON'
{"log":{"version":"1.2","creator":{"name":"fixture","version":"1"},"entries":[{"startedDateTime":"2020-01-01T00:00:00.000Z","time":1,"request":{"method":"GET","url":"http://127.0.0.1/api/items/1","httpVersion":"HTTP/1.1","headers":[],"queryString":[],"cookies":[],"headersSize":-1,"bodySize":0},"response":{"status":200,"statusText":"OK","httpVersion":"HTTP/1.1","headers":[{"name":"Content-Type","value":"application/json"}],"cookies":[],"content":{"size":8,"mimeType":"application/json","text":"{\"id\":1}"},"redirectURL":"","headersSize":-1,"bodySize":8},"cache":{},"timings":{"send":0,"wait":1,"receive":0}}]}}
JSON
rea inspect-web-network-capture "$case_dir/session.har" har --format json > "$case_dir/capture.json"
python3 - "$case_dir" <<'PYTHON'
import json, pathlib, sys
root = pathlib.Path(sys.argv[1])
capture = json.loads((root / "capture.json").read_text())
(root / "view.json").write_text(json.dumps({
    "source": {"kind": "inline", "evidence": capture},
    "view": {"kind": "environment-manifest"}
}))
PYTHON
rea inspect-analysis-view "$case_dir/view.json" --format json > "$case_dir/manifest.json"
rea environment-serve "$case_dir/manifest.json" --evidence "$case_dir/capture.json" --host 256.256.256.256 --port 8765 --json
rea environment-serve "$case_dir/manifest.json" --evidence "$case_dir/capture.json" --host 256.256.256.256 --port 8766 --json
MCP_HOST=256.256.256.256 rea environment-serve "$case_dir/manifest.json" --evidence "$case_dir/capture.json" --json

Both projection commands exited 0. Each serving attempt exited 1 with the same lookup failure and port/process advice; the reported ports were 8765, 8766 and 0 respectively.

Expected behavior

Recovery advice for a host lookup failure should identify --host or MCP_HOST and tell the caller to correct or resolve that host. Startup should still fail and preserve the useful lookup diagnostic. Genuine occupied-port failures should retain port/process advice.

Source-grounded expectation: docs/cli.md:375-396 and CLI help describe independent host/port selection (flags, then environment variables, then defaults). src/domain/analysisErrorProjection.ts projects the recovery action for callers. Changing the port cannot correct a host lookup failure. This report does not require a different error category.

Impact and scope

P3 wording defect: following the recovery advice repeats the refusal. The error already identifies the host and lookup failure. No data loss, isolation failure or additional functional failure was observed. Two explicit ports, the ephemeral default, and a second invalid host (bad host!) were tested; broader DNS failure coverage is unknown.

Verified workaround: selecting --host 127.0.0.1 --port 0 started the same manifest with one tool; SIGINT to the exact CLI PID returned status: stopped and exit 130. An independently owned loopback socket occupying the requested port produced EADDRINUSE with the applicable existing port/process advice. All CLI processes and the owned socket were closed after verification.

REA version

rea-agents 6.7.0; source commit 074768901f3cdc8205b61773fb1faf6f6c7b3ca8.

Runtime and platform

Node.js v26.12.0; Darwin 27.0.0; arm64. No native analysis provider was involved.

Target and artifact context

Synthetic one-entry HAR, projected capture Evidence and its matching environment manifest; one retained JSON response for GET http://127.0.0.1/api/items/1.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

The first invalid-host command above returned the following JSON with exit 1:

{"error":"Application workflow failed","code":"resource_constraint","category":"resource_constraint","message":"MCP HTTP listener could not bind: getaddrinfo ENOTFOUND 256.256.256.256","retryable":false,"remediation":{"action":"Choose another --port or MCP_PORT, or stop the process using it."},"details":{"operation":"environment-serve","resource":"transport","reason":"MCP HTTP listener could not bind: getaddrinfo ENOTFOUND 256.256.256.256","reported_limits":{"host":"256.256.256.256","port":8765}}}

The second explicit-port command and the MCP_HOST command returned the same lookup failure and recovery action. The independent verifier also ran --host 'bad host!' --port 0 --json against the same manifest/capture pair and observed the same advice.

Typed outcome or recovery expected

Keep the failed-startup result and underlying host lookup reason; make remediation.action address the selected host. Preserve appropriate port/process advice for EADDRINUSE.

Analysis or suspected cause

Source-derived reasoning: src/cli/environmentCommands.ts:50-66 supplies the same port/process recovery action for every listener error. The startup catch passes StreamableHttpListenError through that helper. src/server/http/listenHttpServer.ts, src/server/http/serveStreamableHttp.ts:528-537 and src/server/http/streamableHttpListenError.ts corroborate the host-lookup path. The runtime observations above establish the caller-visible result.

Additional context

Prepared with AI assistance and independently reproduced using the built baseline CLI in isolated home/XDG directories. The relevant source files are unchanged through checked upstream main commit 052956af3416fa01d93837e54fdec3ad2739f6d1. No new runtime reproduction was performed during submission.

NOT_ENOUGH_INFO: the last known good version and whether this is a regression were not established.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5455 ### 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 CLI ### Observed behavior `environment-serve` correctly reports `getaddrinfo ENOTFOUND` for an unresolvable listener host, but `remediation.action` tells the caller to change the port or stop its owner. Independent verification reproduced the same advice with two explicit ports and the ephemeral default. Correcting the host started the same manifest. ### Reproduction The following public CLI sequence was independently executed against the built source checkout. The fixture is synthetic; its recorded URL is never fetched. ```sh case_dir="$(mktemp -d)" mkdir -p "$case_dir/home" "$case_dir/config" "$case_dir/data" "$case_dir/cache" "$case_dir/state" export HOME="$case_dir/home" export XDG_CONFIG_HOME="$case_dir/config" XDG_DATA_HOME="$case_dir/data" export XDG_CACHE_HOME="$case_dir/cache" XDG_STATE_HOME="$case_dir/state" unset MCP_HOST MCP_PORT ENVIRONMENT_NAME rea() { node scripts/rea.mjs "$@"; } cat > "$case_dir/session.har" <<'JSON' {"log":{"version":"1.2","creator":{"name":"fixture","version":"1"},"entries":[{"startedDateTime":"2020-01-01T00:00:00.000Z","time":1,"request":{"method":"GET","url":"http://127.0.0.1/api/items/1","httpVersion":"HTTP/1.1","headers":[],"queryString":[],"cookies":[],"headersSize":-1,"bodySize":0},"response":{"status":200,"statusText":"OK","httpVersion":"HTTP/1.1","headers":[{"name":"Content-Type","value":"application/json"}],"cookies":[],"content":{"size":8,"mimeType":"application/json","text":"{\"id\":1}"},"redirectURL":"","headersSize":-1,"bodySize":8},"cache":{},"timings":{"send":0,"wait":1,"receive":0}}]}} JSON rea inspect-web-network-capture "$case_dir/session.har" har --format json > "$case_dir/capture.json" python3 - "$case_dir" <<'PYTHON' import json, pathlib, sys root = pathlib.Path(sys.argv[1]) capture = json.loads((root / "capture.json").read_text()) (root / "view.json").write_text(json.dumps({ "source": {"kind": "inline", "evidence": capture}, "view": {"kind": "environment-manifest"} })) PYTHON rea inspect-analysis-view "$case_dir/view.json" --format json > "$case_dir/manifest.json" rea environment-serve "$case_dir/manifest.json" --evidence "$case_dir/capture.json" --host 256.256.256.256 --port 8765 --json rea environment-serve "$case_dir/manifest.json" --evidence "$case_dir/capture.json" --host 256.256.256.256 --port 8766 --json MCP_HOST=256.256.256.256 rea environment-serve "$case_dir/manifest.json" --evidence "$case_dir/capture.json" --json ``` Both projection commands exited 0. Each serving attempt exited 1 with the same lookup failure and port/process advice; the reported ports were 8765, 8766 and 0 respectively. ### Expected behavior Recovery advice for a host lookup failure should identify `--host` or `MCP_HOST` and tell the caller to correct or resolve that host. Startup should still fail and preserve the useful lookup diagnostic. Genuine occupied-port failures should retain port/process advice. Source-grounded expectation: `docs/cli.md:375-396` and CLI help describe independent host/port selection (flags, then environment variables, then defaults). `src/domain/analysisErrorProjection.ts` projects the recovery action for callers. Changing the port cannot correct a host lookup failure. This report does not require a different error category. ### Impact and scope P3 wording defect: following the recovery advice repeats the refusal. The error already identifies the host and lookup failure. No data loss, isolation failure or additional functional failure was observed. Two explicit ports, the ephemeral default, and a second invalid host (`bad host!`) were tested; broader DNS failure coverage is unknown. Verified workaround: selecting `--host 127.0.0.1 --port 0` started the same manifest with one tool; SIGINT to the exact CLI PID returned `status: stopped` and exit 130. An independently owned loopback socket occupying the requested port produced `EADDRINUSE` with the applicable existing port/process advice. All CLI processes and the owned socket were closed after verification. ### REA version rea-agents 6.7.0; source commit `074768901f3cdc8205b61773fb1faf6f6c7b3ca8`. ### Runtime and platform Node.js v26.12.0; Darwin 27.0.0; arm64. No native analysis provider was involved. ### Target and artifact context Synthetic one-entry HAR, projected capture Evidence and its matching environment manifest; one retained JSON response for `GET http://127.0.0.1/api/items/1`. ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence The first invalid-host command above returned the following JSON with exit 1: ```json {"error":"Application workflow failed","code":"resource_constraint","category":"resource_constraint","message":"MCP HTTP listener could not bind: getaddrinfo ENOTFOUND 256.256.256.256","retryable":false,"remediation":{"action":"Choose another --port or MCP_PORT, or stop the process using it."},"details":{"operation":"environment-serve","resource":"transport","reason":"MCP HTTP listener could not bind: getaddrinfo ENOTFOUND 256.256.256.256","reported_limits":{"host":"256.256.256.256","port":8765}}} ``` The second explicit-port command and the `MCP_HOST` command returned the same lookup failure and recovery action. The independent verifier also ran `--host 'bad host!' --port 0 --json` against the same manifest/capture pair and observed the same advice. ### Typed outcome or recovery expected Keep the failed-startup result and underlying host lookup reason; make `remediation.action` address the selected host. Preserve appropriate port/process advice for `EADDRINUSE`. ### Analysis or suspected cause Source-derived reasoning: `src/cli/environmentCommands.ts:50-66` supplies the same port/process recovery action for every listener error. The startup catch passes `StreamableHttpListenError` through that helper. `src/server/http/listenHttpServer.ts`, `src/server/http/serveStreamableHttp.ts:528-537` and `src/server/http/streamableHttpListenError.ts` corroborate the host-lookup path. The runtime observations above establish the caller-visible result. ### Additional context Prepared with AI assistance and independently reproduced using the built baseline CLI in isolated home/XDG directories. The relevant source files are unchanged through checked upstream main commit `052956af3416fa01d93837e54fdec3ad2739f6d1`. No new runtime reproduction was performed during submission. NOT_ENOUGH_INFO: the last known good version and whether this is a regression were not established.

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

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

TL;DR: This looks fixed on main. Closing is the maintainers' call.

Checked on main b3aadaf47 (Linux, Node 24.18.0). environment-serve --host 256.256.256.256 exits 1 with getaddrinfo ENOTFOUND. The remediation now says "Check --host or MCP_HOST and host name resolution", with no port advice. Ports 8765 and 8766 give the same result. This matches the fix in 0c440bfc0.

Not run

The ephemeral default port.
Starting the manifest with a corrected host.

Thanks, coygeek, for the clear report.

Commands

Used the issue's fixture recipe: a one-entry HAR, then inspect-web-network-capture ... har --format json, then inspect-analysis-view with the environment-manifest view. Isolated HOME, XDG and TMPDIR.

node scripts/rea.mjs environment-serve manifest.json --evidence capture.json --host 256.256.256.256 --port 8765 --json
node scripts/rea.mjs environment-serve manifest.json --evidence capture.json --host 256.256.256.256 --port 8766 --json

Both exit 1, stderr empty. Output excerpt:

{"code":"resource_constraint","message":"MCP HTTP listener startup failed: getaddrinfo ENOTFOUND 256.256.256.256","remediation":{"action":"Check --host or MCP_HOST and host name resolution; correct the value or resolve the lookup failure, then retry."},"details":{"diagnostics":{"listener_failure":{"kind":"host_lookup","system_code":"ENOTFOUND"}}}}

Test setup

Box: Nobara 44 (Fedora 44 base), Linux 7.2.11
CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads
RAM: 32 GB DDR4-3600
Node: 24.18.0
Head: b3aadaf47
Other: another job shared the box during the run

🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 20, 2026): **TL;DR:** This looks fixed on main. Closing is the maintainers' call. Checked on main b3aadaf47 (Linux, Node 24.18.0). `environment-serve --host 256.256.256.256` exits 1 with `getaddrinfo ENOTFOUND`. The remediation now says "Check --host or MCP_HOST and host name resolution", with no port advice. Ports 8765 and 8766 give the same result. This matches the fix in 0c440bfc0. ### Not run - The ephemeral default port. - Starting the manifest with a corrected host. Thanks, coygeek, for the clear report. <details> <summary>Commands</summary> Used the issue's fixture recipe: a one-entry HAR, then `inspect-web-network-capture ... har --format json`, then `inspect-analysis-view` with the `environment-manifest` view. Isolated HOME, XDG and TMPDIR. ```sh node scripts/rea.mjs environment-serve manifest.json --evidence capture.json --host 256.256.256.256 --port 8765 --json node scripts/rea.mjs environment-serve manifest.json --evidence capture.json --host 256.256.256.256 --port 8766 --json ``` Both exit 1, stderr empty. Output excerpt: ```json {"code":"resource_constraint","message":"MCP HTTP listener startup failed: getaddrinfo ENOTFOUND 256.256.256.256","remediation":{"action":"Check --host or MCP_HOST and host name resolution; correct the value or resolve the lookup failure, then retry."},"details":{"diagnostics":{"listener_failure":{"kind":"host_lookup","system_code":"ENOTFOUND"}}}} ``` </details> <details> <summary>Test setup</summary> - Box: Nobara 44 (Fedora 44 base), Linux 7.2.11 - CPU: AMD Ryzen 9 5900X, 12 cores / 24 threads - RAM: 32 GB DDR4-3600 - Node: 24.18.0 - Head: b3aadaf47 - Other: another job shared the box during the run </details> 🤖 Generated with Claude Code (Sonnet 5.5, verified by Opus 5.5) 🦊

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 21, 2026):

Closing as fixed on main by github.com/morluto/rea@0c440bfc07, retained at 67a6477f01.

Listener error interpretation distinguishes host lookup failures, and environment-serve directs those failures to --host/MCP_HOST while retaining port recovery for address-in-use. The CLI remediation regression covers the reported invalid-host trigger.

This closure follows current-main producer and regression source inspection and the existing issue evidence. Tests and runtime reproductions were not rerun in this audit; no additional platform/provider coverage is implied.

@morluto commented on GitHub (Oct 21, 2026): Closing as fixed on main by https://github.com/morluto/rea/commit/0c440bfc07f3cb343e2e836d27cccaed539cfe9c, retained at 67a6477f011ae358fc333e5a6e26c86d932654ed. Listener error interpretation distinguishes host lookup failures, and environment-serve directs those failures to --host/MCP_HOST while retaining port recovery for address-in-use. The CLI remediation regression covers the reported invalid-host trigger. This closure follows current-main producer and regression source inspection and the existing issue evidence. Tests and runtime reproductions were not rerun in this audit; no additional platform/provider coverage is implied.

bsakaguchi referenced this issue

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

[PR #3897] [MERGED] fix(javascript): keep releases through a replaced handle as candidates #5957

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

No description provided.

Rows
Columns