[PR #4412] fix(browser): bind module verifier fixture to browser-safe ports #6223

New issue

Open

opened 2026-10-31 01:12:49 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4412
Author: @dajiaohuang
Created: 10/16/2026
Status: 🔄 Open

Base: main ← Head: fix/browser-module-safe-port-20261016

📝 Commits (1)

0b30b90 fix(browser): bind module verifier fixture to browser-safe ports

📊 Changes

1 file changed (+30 additions, -5 deletions)

View changed files

📝 scripts/fixtures/browser-module-site.mjs (+30 -5)

📄 Description

Summary

Make the source-owned module site used by the real-browser verifier bind to browser-safe loopback ports instead of accepting any OS-assigned port.

Problem and expected behavior

On Windows, the existing real-browser verification run selected port 6667 through listen(0). Chrome rejected the module fixture with ERR_UNSAFE_PORT before its import-map/module assertions could run. A healthy fixture should be loadable by the browser. This repairs the verifier's actual server setup, not merely its assertions. No companion issue was opened for this reproduced fixture failure.

Change and scope

Try ports 49152–49215 on 127.0.0.1, skipping occupied/denied ports and surfacing other binding errors. Fail explicitly after the bounded allocation budget. The fixture API, module graph and verifier assertions are unchanged. No production browser/target admission policy is relaxed, and no capability is added; a separate advance maintainer scope decision is not applicable to this routine fixture fix.

Contract and boundary impact

Semantic owner / earliest stage: startBrowserModuleSite loopback listener allocation, before browser navigation.
CLI/MCP schemas, captured evidence, provider behavior and generated/package metadata: unchanged.
Existing verifier workflow runs source-owned browser scripts and uses owned loopback HTTP sites and a disposable browser profile. It does not target an external website; normal fixture/browser cleanup remains with the existing owners.
Launch or attach to a process (existing verifier browser).
Inject instrumentation or run scripts/code (existing source-owned fixture modules).
Contact network services (owned loopback fixture only).

Evidence and regression coverage

Prior executed baseline: scripts/verify-real-browser.mjs failed on the source-owned module site at port 6667 with Chrome ERR_UNSAFE_PORT.
The unchanged candidate then passed that complete real-browser verifier at base 4135c911d3a3414b17fcd8954a15f6c7ec6ae8f4 with Chrome 155.0.8059.41 (verified: true), including CLI/stdio-MCP capture and module tracing. This is prior revision evidence, not a fresh full-verifier pass on this head.
Current-base focused real-browser check (Windows, Node 24.18.0, Chrome 155.0.8059.80): reserved port 49152, started two module sites, observed allocation of 49153 and 49154, navigated Chrome to the first site and verified ready state, scoped/package exports, repeated-module identity and distinct fragment instances. The owned browser and all three listeners were closed successfully. This targeted check ran from an uncommitted local driver, not a newly added repository test or a CLI/MCP acceptance run.

Validation performed

Base: 2c7583599b9ac1c847bd77b1940930fd8d4594c7.

node --check scripts/fixtures/browser-module-site.mjs and git diff --check passed.
Pre-commit formatting/lint passed; pre-push npm run check:fast passed (typecheck/lint: 2 successful tasks).
Focused real Chrome check above passed on the exact fixture change.
Full npm run check and a fresh complete CLI/MCP browser lane remain outstanding. The clean checkout lacks the Windows native manifest/addon required by run-exclusive build commands; no native artifact or target-policy gate was bypassed.
EACCES handling and exhausting all 64 candidate ports were not executed. Linux/macOS were not tested in this pass. No performance improvement is claimed or measured.

Compatibility, safety, and release

No breaking API, migration or package/release metadata changes. The intentionally bounded port range can be exhausted; this now produces an explicit failure rather than a hung bind. Existing real-provider evidence does not establish unrelated Hopper/Ghidra, firmware, capture or OS acceptance.

Author readiness

Human owner: @dajiaohuang (PR author by default). AI-assisted draft submitted for the author's review; no human review or readiness declaration is asserted.

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

Human review/readiness and applicable current-head checks are complete.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/4412 **Author:** [@dajiaohuang](https://github.com/dajiaohuang) **Created:** 10/16/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/browser-module-safe-port-20261016` --- ### 📝 Commits (1) - [`0b30b90`](https://github.com/morluto/rea/commit/0b30b90ff34c6fb51246ee61f3234dba95b7f0f5) fix(browser): bind module verifier fixture to browser-safe ports ### 📊 Changes **1 file changed** (+30 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `scripts/fixtures/browser-module-site.mjs` (+30 -5) </details> ### 📄 Description ## Summary Make the source-owned module site used by the real-browser verifier bind to browser-safe loopback ports instead of accepting any OS-assigned port. ## Problem and expected behavior On Windows, the existing real-browser verification run selected port 6667 through `listen(0)`. Chrome rejected the module fixture with `ERR_UNSAFE_PORT` before its import-map/module assertions could run. A healthy fixture should be loadable by the browser. This repairs the verifier's actual server setup, not merely its assertions. No companion issue was opened for this reproduced fixture failure. ## Change and scope Try ports 49152–49215 on `127.0.0.1`, skipping occupied/denied ports and surfacing other binding errors. Fail explicitly after the bounded allocation budget. The fixture API, module graph and verifier assertions are unchanged. No production browser/target admission policy is relaxed, and no capability is added; a separate advance maintainer scope decision is not applicable to this routine fixture fix. ## Contract and boundary impact - Semantic owner / earliest stage: `startBrowserModuleSite` loopback listener allocation, before browser navigation. - CLI/MCP schemas, captured evidence, provider behavior and generated/package metadata: unchanged. - Existing verifier workflow runs source-owned browser scripts and uses owned loopback HTTP sites and a disposable browser profile. It does not target an external website; normal fixture/browser cleanup remains with the existing owners. - [x] Launch or attach to a process (existing verifier browser). - [x] Inject instrumentation or run scripts/code (existing source-owned fixture modules). - [x] Contact network services (owned loopback fixture only). ## Evidence and regression coverage - Prior executed baseline: `scripts/verify-real-browser.mjs` failed on the source-owned module site at port 6667 with Chrome `ERR_UNSAFE_PORT`. - The unchanged candidate then passed that complete real-browser verifier at base `4135c911d3a3414b17fcd8954a15f6c7ec6ae8f4` with Chrome 155.0.8059.41 (`verified: true`), including CLI/stdio-MCP capture and module tracing. This is prior revision evidence, not a fresh full-verifier pass on this head. - Current-base focused real-browser check (Windows, Node 24.18.0, Chrome 155.0.8059.80): reserved port 49152, started two module sites, observed allocation of 49153 and 49154, navigated Chrome to the first site and verified ready state, scoped/package exports, repeated-module identity and distinct fragment instances. The owned browser and all three listeners were closed successfully. This targeted check ran from an uncommitted local driver, not a newly added repository test or a CLI/MCP acceptance run. ## Validation performed Base: `2c7583599b9ac1c847bd77b1940930fd8d4594c7`. - `node --check scripts/fixtures/browser-module-site.mjs` and `git diff --check` passed. - Pre-commit formatting/lint passed; pre-push `npm run check:fast` passed (typecheck/lint: 2 successful tasks). - Focused real Chrome check above passed on the exact fixture change. - Full `npm run check` and a fresh complete CLI/MCP browser lane remain outstanding. The clean checkout lacks the Windows native manifest/addon required by `run-exclusive` build commands; no native artifact or target-policy gate was bypassed. - EACCES handling and exhausting all 64 candidate ports were not executed. Linux/macOS were not tested in this pass. No performance improvement is claimed or measured. ## Compatibility, safety, and release No breaking API, migration or package/release metadata changes. The intentionally bounded port range can be exhausted; this now produces an explicit failure rather than a hung bind. Existing real-provider evidence does not establish unrelated Hopper/Ghidra, firmware, capture or OS acceptance. ## Author readiness Human owner: @dajiaohuang (PR author by default). AI-assisted draft submitted for the author's review; no human review or readiness declaration is asserted. - [ ] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [ ] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [ ] I declare this PR ready for initial maintainer review. ## Before merge - [ ] Human review/readiness and applicable current-head checks are complete. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

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

bsakaguchi referenced this issue

2026-11-01 21:46:10 +00:00

[PR #6223] [MERGED] fix(browser): keep target detail when attributing CDP failures #7210

bsakaguchi referenced this issue

2026-11-01 21:46:48 +00:00

[PR #6340] [MERGED] fix(browser): keep refresh guidance for a missing CDP target #7292