[Feature] Attach to Hermes application fails under Node.js v24.21.0 with Inspector network inspection

从 src/cdp-proxy/debuggerEndpointHelper.ts 和针对 debuggerEndpointHelper 的专项测试入手；追踪 /json/list 响应的收集和解码过程。在 Inspector 中检查网络以复现空响应体，然后通过专项测试以及在 Extension Development Host 中连接 Hermes 目标来验证修复。

Description

When debugging React Native Tools in an Extension Development Host, Attach to Hermes application fails with error codes 1501 and 1410, even though Metro exposes a valid Hermes debugging target.

Metro's /json/list endpoint returns HTTP 200 and contains a valid webSocketDebuggerUrl. However, the extension reads an empty response body under the debugger and reports that no debuggable target is available.

Steps to reproduce

1. Build React Native Tools and start it using the Launch Extension configuration.
2. Open a React Native 0.87.1 project in the Extension Development Host.
3. Start Metro on port 8081.
4. Run a Debug build of the application with Hermes enabled on an Android emulator.
5. Confirm that http://localhost:8081/json/list returns a target containing a valid webSocketDebuggerUrl.
6. Execute Attach to Hermes application in the Extension Development Host.

This was reproduced with Node.js v24.21.0 in the Extension Host. The exact affected version range and Inspector configuration requirements have not been established.

Actual behavior

Attaching fails with the following error:

Attaching to the application
Connecting to 8081 port

An error occurred while attaching debugger to the application.
Could not connect to the debug target at http://localhost:8081:
Could not find any debuggable target with a valid webSocketDebuggerUrl
(error code 1501) (error code 1410)

Expected behavior

The extension should read Metro's response, discover the available Hermes debugging target, and attach successfully.

Investigation

Metro exposes a valid debugging target

Requesting /json/list using curl returns HTTP 200 and a valid target:

[
  {
    "title": "com.rn_0_87_1 (Google sdk_gphone64_x86_64)",
    "description": "React Native Bridgeless [C++ connection]",
    "webSocketDebuggerUrl": "ws://localhost:8081/inspector/debug?device=<device-id>&page=1"
  }
]

Inspecting the request and response inside the Extension Host showed:

{
  "method": "GET",
  "path": "/json/list",
  "host": "localhost:8081",
  "status": 200,
  "contentLength": "845",
  "remoteAddress": "127.0.0.1"
}

However, the body passed to JSON.parse() was an empty string:

data.length
0

JSON.stringify(data)
'""'

Running the same HTTP read logic in a standalone Node process successfully read the response:

status 200 length 845
chunk length 845
end length 845 complete true

Possible interaction with Inspector network inspection

The original response handling in src/cdp-proxy/debuggerEndpointHelper.ts uses:

let data = "";
response.setEncoding("utf8");
response.on("data", (chunk: string) => {
    data += chunk;
});
response.on("end", () => fulfill(data));
response.on("error", reject);

During debugging, the response had an Inspector-injected data listener before the extension's listener. The injected listener accessed:

Network.dataReceived({
    requestId: request[kInspectorRequestId],
    timestamp: getMonotonicTime(),
    dataLength: chunk.byteLength,
    encodedDataLength: chunk.byteLength,
    data: chunk,
});

Calling setEncoding("utf8") makes response chunks strings rather than Buffers. Strings do not have a byteLength property.

The extension's data callback was not observed executing, while the response's end event fired.

These observations suggest an interaction between Inspector network inspection and string response chunks. An exception inside the Inspector listener was not directly captured, so the precise upstream failure mechanism remains unconfirmed.

The original error is hidden

fetchJson() catches JSON parsing errors and returns {}.

Consequently, the empty-body parsing failure is converted into a “no debuggable target” error, making the underlying response-reading problem difficult to identify.

Related upstream issues

The observed behavior appears consistent with the following Node.js Inspector reports:

• nodejs/node#64494 — https://github.com/nodejs/node/issues/64494
• nodejs/node#66551 — https://github.com/nodejs/node/issues/66551

These reports describe interactions between HTTP response encoding and Inspector network inspection.

In this environment, the Extension Host used Node.js v24.21.0. We observed an Inspector-injected listener accessing chunk.byteLength, while the extension configured response chunks as strings.

We have not confirmed that the underlying cause is identical to those reports, nor established the first affected Node.js version.

Fix and validation

A local change to src/cdp-proxy/debuggerEndpointHelper.ts resolved Attach to Hermes application in this environment.

The change:

1. Removes response.setEncoding("utf8").
2. Collects raw byte chunks.
3. Concatenates and decodes the complete response as UTF-8 when the response ends.

const chunks: Uint8Array[] = [];
response.on("data", (chunk: Buffer) => {
    chunks.push(new Uint8Array(chunk.buffer, chunk.byteOffset, chunk.byteLength));
});
response.on("end", () => {
    fulfill(Buffer.concat(chunks).toString("utf8"));
});
response.on("error", reject);

This avoids delivering string chunks to the Inspector network listener and preserves UTF-8 characters split across response chunks.

Validation results

• npm.cmd run build completed successfully.
• All 11 focused debuggerEndpointHelper tests passed.
• Added a regression test covering UTF-8 decoding and verifying that the response reader does not call setEncoding().
• After rebuilding and restarting the Extension Development Host, Attach to Hermes application succeeded.

The automated test covers HTTP response handling, but does not reproduce the full Inspector-enabled Extension Host environment.

Debug output

process.version
'v24.21.0'

url
'http://localhost:8081/json/list'

data.length
0

JSON.stringify(data)
'""'

[RN HTTP END] 200 true

Attaching to the application
Connecting to 8081 port

An error occurred while attaching debugger to the application.
Could not connect to the debug target at http://localhost:8081:
Could not find any debuggable target with a valid webSocketDebuggerUrl
(error code 1501) (error code 1410)