[GH-ISSUE #6523] [Bug] Partial HTTP inventories report changes when an omitted repeat has different response facts #3914

Closed
opened 2026-10-31 00:45:12 +00:00 by bsakaguchi · 0 comments
Owner

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

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

Source-only finding at revision 49c9c9d4a14cc7d5509ec28a304dab48f85cb045; no runtime reproduction was performed.

compare_web_captures can classify the network dimension as changed when an incomplete capture merely omits one repeated request with different response metadata. For example, both observation windows can contain the same two GET https://app.example.test/a requests, returning 200 and 503. If the before capture retains both and the after capture retains only the 200 request with a recorded network omission, the grouping/filter branches derive a modified network group even though the missing 503 request could explain the entire difference.

Reproduction

Proposed, not run. No provider integration is needed; this targets the public passive-capture comparison input.

  1. Construct two otherwise equal valid passive snapshots, using the existing normalized passive network fixture as a starting point.
  2. Give the before snapshot two requests with the same URL, method and resource type. Keep their MIME type, byte count, initiator and other projected fields equal, but set their statuses to 200 and 503. Use different capture-local request IDs.
  3. Give the after snapshot just the 200 request. Record dropped_events.network_requests = 1 and dropped_events.total = 1, with matching truncated completeness. Leave HTTP body-shape capture unselected on both snapshots.
  4. Submit { before: { inspection: before }, after: { inspection: after } } to compare_web_captures, or its equivalent compare-web-captures CLI input.
  5. Source-derived result: one network modified change. The proposed check should instead require unknown for this group: the omitted request can have exactly the before capture's 503 facts.

Execution frequency and an actual returned result: NOT_ENOUGH_INFO; this proposed check was not executed.

Expected behavior

An omitted member of a repeated-request group must not by itself prove that group changed. This input should remain unknown unless retained facts and the available coverage establish a difference independently of the missing request.

The comparator's own grouping comment says to retain known content “without interpreting missing rows as change.” Its existing omission test requires unknown when an omitted repeat has identical projected facts. A repeat with different facts is still potentially missing rather than changed.

Impact and scope

Source-derived consequence: false positive network modifications from partial repeated-request inventories. Distinct statuses, sizes, redirect facts or other projected content can make the omitted member's fingerprint unique, whereas identical omitted repeats are already handled. No security impact is asserted.

The stored request records and omission counts remain available for manual inspection. Workaround: treat this comparison result as inconclusive and compare the retained samples together with their coverage limits. Live-provider frequency and additional affected workloads are NOT_ENOUGH_INFO.

REA version

Source revision 49c9c9d4a14cc7d5509ec28a304dab48f85cb045 (main; package metadata says 6.7.0).

The same grouping and modification-filter branches are present in release-tag source rea-agents-6.7.0, commit 27dc42d10249f0410904a75c0997842eb03b931c, as inspected with git show. This is a source-presence observation, not a claim that the published package was reproduced or verified affected.

Runtime and platform

NOT_ENOUGH_INFO — source inspection only; no REA runtime, Node.js/platform compatibility run, or browser/provider execution was performed.

Target and artifact context

Two normalized passive web-page capture snapshots with a repeated HTTP request identity and an explicitly incomplete network inventory; no private target or artifact was used.

Interface

MCP

The same domain comparator also backs the CLI.

Earliest failure stage

Transport or result projection

Relevant output or evidence

Evidence was obtained by reading the exact source revision and the existing comparison fixture/test; no runtime output is available.

(projection.inventoryComplete ? values : [...new Set(values)]).sort()

Consequently {fingerprint(200), fingerprint(503)} differs from {fingerprint(200)} despite the recorded omission.

change === "modified" || /* inventory completeness check */

That promotes this omission-only set difference to changed. Actual returned JSON and live-browser coverage are NOT_ENOUGH_INFO; the reasoning above is source-derived.

Additional context

Related closed #3386 covered omitted repeats with identical projected facts. Current source deduplicates equal fingerprints for incomplete inventories; this report concerns an omitted repeat with distinct response facts, which survives that reduction. Open #4211 concerns omitted initiator URLs inside retained requests, whereas this case omits a whole request with known response facts. No matching open report was found.

Triage assessment

  • Impact level: P2
  • Assessment status: provisional
  • Impact basis: The inspected branches can report a false network modification when incomplete sampling drops a distinct repeat; runtime behavior and real-world incidence have not been reproduced.
  • Workaround status: unverified
  • Workaround basis: The inputs retain individual request facts and omission counts for manual assessment, but that procedure was not executed in this source-only audit.
Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6523 ### 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 Source-only finding at revision `49c9c9d4a14cc7d5509ec28a304dab48f85cb045`; no runtime reproduction was performed. `compare_web_captures` can classify the network dimension as `changed` when an incomplete capture merely omits one repeated request with different response metadata. For example, both observation windows can contain the same two `GET https://app.example.test/a` requests, returning 200 and 503. If the before capture retains both and the after capture retains only the 200 request with a recorded network omission, the grouping/filter branches derive a `modified` network group even though the missing 503 request could explain the entire difference. ### Reproduction Proposed, not run. No provider integration is needed; this targets the public passive-capture comparison input. 1. Construct two otherwise equal valid passive snapshots, using the existing normalized [passive network fixture](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/tests/fixtures/passiveNetworkCapture.ts#L10-L89) as a starting point. 2. Give the before snapshot two requests with the same URL, method and resource type. Keep their MIME type, byte count, initiator and other projected fields equal, but set their statuses to 200 and 503. Use different capture-local request IDs. 3. Give the after snapshot just the 200 request. Record `dropped_events.network_requests = 1` and `dropped_events.total = 1`, with matching truncated completeness. Leave HTTP body-shape capture unselected on both snapshots. 4. Submit `{ before: { inspection: before }, after: { inspection: after } }` to `compare_web_captures`, or its equivalent `compare-web-captures` CLI input. 5. Source-derived result: one network `modified` change. The proposed check should instead require `unknown` for this group: the omitted request can have exactly the before capture's 503 facts. Execution frequency and an actual returned result: `NOT_ENOUGH_INFO`; this proposed check was not executed. ### Expected behavior An omitted member of a repeated-request group must not by itself prove that group changed. This input should remain unknown unless retained facts and the available coverage establish a difference independently of the missing request. The comparator's own [grouping comment](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/webCaptureDiff.ts#L578-L585) says to retain known content “without interpreting missing rows as change.” Its [existing omission test](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/webCaptureDiff.network.test.ts#L131-L151) requires unknown when an omitted repeat has identical projected facts. A repeat with different facts is still potentially missing rather than changed. ### Impact and scope Source-derived consequence: false positive network modifications from partial repeated-request inventories. Distinct statuses, sizes, redirect facts or other projected content can make the omitted member's fingerprint unique, whereas identical omitted repeats are already handled. No security impact is asserted. The stored request records and omission counts remain available for manual inspection. Workaround: treat this comparison result as inconclusive and compare the retained samples together with their coverage limits. Live-provider frequency and additional affected workloads are `NOT_ENOUGH_INFO`. ### REA version Source revision `49c9c9d4a14cc7d5509ec28a304dab48f85cb045` (main; package metadata says 6.7.0). The same grouping and modification-filter branches are present in release-tag source `rea-agents-6.7.0`, commit `27dc42d10249f0410904a75c0997842eb03b931c`, as inspected with `git show`. This is a source-presence observation, not a claim that the published package was reproduced or verified affected. ### Runtime and platform `NOT_ENOUGH_INFO` — source inspection only; no REA runtime, Node.js/platform compatibility run, or browser/provider execution was performed. ### Target and artifact context Two normalized passive web-page capture snapshots with a repeated HTTP request identity and an explicitly incomplete network inventory; no private target or artifact was used. ### Interface MCP The same domain comparator also backs the CLI. ### Earliest failure stage Transport or result projection ### Relevant output or evidence Evidence was obtained by reading the exact source revision and the existing comparison fixture/test; no runtime output is available. - [Request grouping identity](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/webCaptureDiff.ts#L252-L257) uses method, URL and resource type, so the 200 and 503 requests share one group. - [Response metadata projection](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/webCaptureDiff.ts#L529-L542) includes the known status in each member fingerprint. - [Incomplete-group reduction](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/webCaptureDiff.ts#L578-L585) removes duplicate fingerprints but hashes the entire remaining set: ```ts (projection.inventoryComplete ? values : [...new Set(values)]).sort() ``` Consequently `{fingerprint(200), fingerprint(503)}` differs from `{fingerprint(200)}` despite the recorded omission. - [Dimension filtering](https://github.com/morluto/rea/blob/49c9c9d4a14cc7d5509ec28a304dab48f85cb045/src/domain/webCaptureDiff.ts#L79-L93) retains every `modified` group even when its inventory is incomplete: ```ts change === "modified" || /* inventory completeness check */ ``` That promotes this omission-only set difference to `changed`. Actual returned JSON and live-browser coverage are `NOT_ENOUGH_INFO`; the reasoning above is source-derived. ### Additional context Related closed [#3386](https://github.com/morluto/rea/issues/3386) covered omitted repeats with identical projected facts. Current source deduplicates equal fingerprints for incomplete inventories; this report concerns an omitted repeat with distinct response facts, which survives that reduction. Open [#4211](https://github.com/morluto/rea/issues/4211) concerns omitted initiator URLs inside retained requests, whereas this case omits a whole request with known response facts. No matching open report was found. ## Triage assessment - Impact level: P2 - Assessment status: provisional - Impact basis: The inspected branches can report a false network modification when incomplete sampling drops a distinct repeat; runtime behavior and real-world incidence have not been reproduced. - Workaround status: unverified - Workaround basis: The inputs retain individual request facts and omission counts for manual assessment, but that procedure was not executed in this source-only audit.
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#3914
No description provided.