[GH-ISSUE #3328] [Bug] Response nodes discard uniquely known request endpoints #1198

Closed
opened 2026-10-15 18:31:56 +00:00 by bsakaguchi · 0 comments
Owner

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

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

analyze-javascript-application retains a literal fetch endpoint on the request node but returns properties.endpoint: null on its uniquely resolved response consumer. The CLI exits with status 0, and the response has a consumed-by edge with resolution: "resolved".

A separate control with two awaited fetches to distinct URLs and respective json() and text() consumers also returns null for both response endpoints. Selecting the returned response node ID in a public semantic trace succeeds, so the consumer itself is retained. These observations concern endpoint identity in response properties; they do not attribute endpoint-trace connectivity to this field alone.

Reproduction

  1. Start from a clean checkout at 8dde6370d0809ad04cda3342d4e6f290f48aa063. From the repository root, install the locked dependencies and build the runtime. The recorded reproduction used an installed dependency tree and built runtime.
npm ci
npm run build:cached
  1. Create an isolated home and application directory containing the complete input below, then run the public CLI from the repository root.
work="$(mktemp -d)"
mkdir "$work/home" "$work/app"
cat > "$work/app/main.js" <<'JS'
export async function load() {
  const response = await fetch("https://example.test/data");
  return response.json();
}
JS
HOME="$work/home" node scripts/rea.mjs analyze-javascript-application "$work/app" --json > "$work/application.json"
  1. Inspect request and response properties and the resolution of their consumer links.
node --input-type=module - "$work/application.json" <<'JS'
import { readFileSync } from "node:fs";
const evidence = JSON.parse(readFileSync(process.argv[2], "utf8"));
const graph = evidence.normalized_result.semantic_graph;
console.log(JSON.stringify(graph.nodes
  .filter(node => ["request", "response"].includes(node.kind))
  .map(node => ({ kind: node.kind, ...node.properties })), null, 2));
console.log(JSON.stringify(graph.relations
  .filter(edge => edge.relation === "consumed-by")
  .map(edge => ({ relation: edge.relation, resolution: edge.resolution })), null, 2));
JS

Expected behavior

The request and its uniquely identified response consumer should preserve https://example.test/data in properties.endpoint. docs/javascript-application-workflows.md:122 states that semantic request and response nodes keep the exact endpoint in this property, and the following paragraph directs callers to read the complete endpoint properties. The endpoint remains a static inference; retaining it does not claim that the request executed.

Impact and scope

Impact level: P2, supported. Ordinary awaited fetch consumers lose documented endpoint identity in retained analysis output, limiting reliable request/response attribution. The bounded reproduction succeeds otherwise and does not lose input files.

Workaround status: unverified. Selecting the response node ID was verified to locate its consumer, but it does not restore the missing endpoint property. A complete alternative for preserving that provenance was not verified.

REA version

6.4.0 (main at 8dde6370d0)

Runtime and platform

Node.js v26.10.0; macOS 27.0.1; architecture was not recorded. Source checkout with a built runtime.

Target and artifact context

An isolated local JavaScript application directory containing the inline main.js above. The returned application Evidence includes the semantic graph, request and response nodes, and their consumed-by relation. No browser or application code execution is required.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

The observed request and response properties were:

[
  {
    "kind": "request",
    "endpoint": "https://example.test/data",
    "method": "fetch",
    "operation_kind": "request"
  },
  {
    "kind": "response",
    "endpoint": null,
    "method": "json",
    "operation_kind": "response-consumer"
  }
]

The CLI exited with status 0, and the response's consumed-by edge had resolution: "resolved". The failure was reproduced through the executed CLI output, with a complete reproduction.

Typed outcome or recovery expected

Run the reproduction and verify that the response preserves the exact request endpoint while retaining its consumer location and static authority. Run a control with two different fetch URLs and different consumers and verify that each response keeps its own endpoint. Responses whose request identity is ambiguous must retain explicit uncertainty rather than acquiring an arbitrary endpoint. Preserve the successful response-node-ID semantic trace control.

Analysis or suspected cause

Source-derived reasoning: src/domain/javascript/javascriptSemanticDataEffects.ts:273 constructs the response-consumer operation, retains linked request IDs, and sets its endpoint to null. src/application/javascript/JavaScriptSemanticGraphDataProjection.ts:132 projects that operation into a response node with the null endpoint. The source agrees with the reproduced output; retaining a unique endpoint must preserve uncertainty for ambiguous request identity.

Additional context

Related #3170 concerns missing boundary-field seed identity; this report concerns a missing response endpoint despite a resolved request link.

Related #3190 concerns route seeds matching generated display labels; this report concerns the response node's retained endpoint property, independently of seed matching.

Related completed #3042 concerns omitted EventSource and sendBeacon endpoint discovery; here the fetch endpoint is already present on the request node and is lost only on its response consumer.

Related completed #404 introduced the broad semantic tracing capability; it does not report this response-endpoint preservation failure.

Originally created by @coygeek on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3328 ### 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 Evidence, artifacts, or reconstruction ### Observed behavior `analyze-javascript-application` retains a literal fetch endpoint on the request node but returns `properties.endpoint: null` on its uniquely resolved response consumer. The CLI exits with status 0, and the response has a `consumed-by` edge with `resolution: "resolved"`. A separate control with two awaited fetches to distinct URLs and respective `json()` and `text()` consumers also returns null for both response endpoints. Selecting the returned response node ID in a public semantic trace succeeds, so the consumer itself is retained. These observations concern endpoint identity in response properties; they do not attribute endpoint-trace connectivity to this field alone. ### Reproduction 1. Start from a clean checkout at `8dde6370d0809ad04cda3342d4e6f290f48aa063`. From the repository root, install the locked dependencies and build the runtime. The recorded reproduction used an installed dependency tree and built runtime. ```sh npm ci npm run build:cached ``` 2. Create an isolated home and application directory containing the complete input below, then run the public CLI from the repository root. ```sh work="$(mktemp -d)" mkdir "$work/home" "$work/app" cat > "$work/app/main.js" <<'JS' export async function load() { const response = await fetch("https://example.test/data"); return response.json(); } JS HOME="$work/home" node scripts/rea.mjs analyze-javascript-application "$work/app" --json > "$work/application.json" ``` 3. Inspect request and response properties and the resolution of their consumer links. ```sh node --input-type=module - "$work/application.json" <<'JS' import { readFileSync } from "node:fs"; const evidence = JSON.parse(readFileSync(process.argv[2], "utf8")); const graph = evidence.normalized_result.semantic_graph; console.log(JSON.stringify(graph.nodes .filter(node => ["request", "response"].includes(node.kind)) .map(node => ({ kind: node.kind, ...node.properties })), null, 2)); console.log(JSON.stringify(graph.relations .filter(edge => edge.relation === "consumed-by") .map(edge => ({ relation: edge.relation, resolution: edge.resolution })), null, 2)); JS ``` ### Expected behavior The request and its uniquely identified response consumer should preserve `https://example.test/data` in `properties.endpoint`. `docs/javascript-application-workflows.md:122` states that semantic request and response nodes keep the exact endpoint in this property, and the following paragraph directs callers to read the complete endpoint properties. The endpoint remains a static inference; retaining it does not claim that the request executed. ### Impact and scope Impact level: P2, supported. Ordinary awaited fetch consumers lose documented endpoint identity in retained analysis output, limiting reliable request/response attribution. The bounded reproduction succeeds otherwise and does not lose input files. Workaround status: unverified. Selecting the response node ID was verified to locate its consumer, but it does not restore the missing endpoint property. A complete alternative for preserving that provenance was not verified. ### REA version 6.4.0 (main at 8dde6370d0809ad04cda3342d4e6f290f48aa063) ### Runtime and platform Node.js v26.10.0; macOS 27.0.1; architecture was not recorded. Source checkout with a built runtime. ### Target and artifact context An isolated local JavaScript application directory containing the inline `main.js` above. The returned application Evidence includes the semantic graph, request and response nodes, and their `consumed-by` relation. No browser or application code execution is required. ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence The observed request and response properties were: ```text [ { "kind": "request", "endpoint": "https://example.test/data", "method": "fetch", "operation_kind": "request" }, { "kind": "response", "endpoint": null, "method": "json", "operation_kind": "response-consumer" } ] ``` The CLI exited with status 0, and the response's `consumed-by` edge had `resolution: "resolved"`. The failure was reproduced through the executed CLI output, with a complete reproduction. ### Typed outcome or recovery expected Run the reproduction and verify that the response preserves the exact request endpoint while retaining its consumer location and static authority. Run a control with two different fetch URLs and different consumers and verify that each response keeps its own endpoint. Responses whose request identity is ambiguous must retain explicit uncertainty rather than acquiring an arbitrary endpoint. Preserve the successful response-node-ID semantic trace control. ### Analysis or suspected cause Source-derived reasoning: `src/domain/javascript/javascriptSemanticDataEffects.ts:273` constructs the response-consumer operation, retains linked request IDs, and sets its endpoint to null. `src/application/javascript/JavaScriptSemanticGraphDataProjection.ts:132` projects that operation into a response node with the null endpoint. The source agrees with the reproduced output; retaining a unique endpoint must preserve uncertainty for ambiguous request identity. ### Additional context Related [#3170](https://github.com/morluto/rea/issues/3170) concerns missing boundary-field seed identity; this report concerns a missing response endpoint despite a resolved request link. Related [#3190](https://github.com/morluto/rea/issues/3190) concerns route seeds matching generated display labels; this report concerns the response node's retained endpoint property, independently of seed matching. Related completed [#3042](https://github.com/morluto/rea/issues/3042) concerns omitted EventSource and sendBeacon endpoint discovery; here the fetch endpoint is already present on the request node and is lost only on its response consumer. Related completed [#404](https://github.com/morluto/rea/issues/404) introduced the broad semantic tracing capability; it does not report this response-endpoint preservation failure.
Sign in to join this conversation.
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#1198
No description provided.