[To3akaRin]

Summary

Offline passive network comparisons now preserve uncertainty when request types, selected metadata, or per-kind inventory coverage are incomplete. Missing body/response content no longer erases a proven HTTP addition; incomplete HTTP coverage cannot establish WebSocket absence.

Follow-up to #2609. The original commits/authors are preserved, integrated with main through b8510ee. Additional review reproduced and repaired nullable redirect-type and duplicate-count false modifications.

Change and ownership

• Keep identity/type ambiguity, selected-content projection and HTTP/WebSocket inventory coverage with webCaptureDiff.ts.
• Exclude potentially matching unknown-type groups before their counts/content fingerprints can invent a match. Skip that endpoint index when all types are known.
• Select only mutually known redirect metadata, including resource type, and have that owner report completeness directly.
• With incomplete HTTP inventory, compare distinct known content samples without claiming duplicate request multiplicity. WebSocket stream inventories/counts require complete WebSocket coverage. Independently known metadata and complete-inventory count changes remain reportable.
• Hash HTTP rows during projection and retain digests rather than an intermediate collection of raw projection objects.
• Give each public CLI case its own deadline and reuse one owned SDK connection for the MCP matrix. No timeout, retry, assertion or CI selection was loosened.

Shared fixes already included in the original branch remain: conservative JavaScript process-configuration escapes, malformed JSON rejection coverage, schema-projection documentation, cancellation at controlled child progress boundaries, and SAZ byte/provenance checks. Current main's redirect response owner, tuple/schema-profile fixes and MCP fault barriers are retained.

CLI/MCP schemas, Evidence and session envelopes remain unchanged by the network fix. It compares supplied observations; no new capture, replay, execution, injection or installation authority is added. This is an ordinary correctness fix within existing scope; an additional capability decision is not applicable.

Executed correctness evidence

Linux, Node 24.18.0 / npm 11.16.0; serial two-CPU / 8 GiB guards:

• Original domain cases: 35 passed after integration. New known↔missing redirect-type cases failed in both directions before repair. Three dropped/truncated/unavailable duplicate-request cases also failed before repair.
• Current domain suite: 45 passed, including negative and positive redirect, HTTP and WebSocket controls. Incomplete capture keeps known metadata changes while retaining uncertainty about counts/absence.
• Full related selection: 196 passed / 3 conditionally skipped across 13 files, including JavaScript configuration/cancellation, JSON, SAZ, CLI and real stdio MCP. The initial aggregate CLI case exceeded its 30-second deadline; splitting its cases fixed this structural failure without increasing timeouts.
• Public matrix: 20 individually tested CLI comparisons plus 20 comparisons on one production SDK connection; 21 tests passed. After current main's contract updates, 51 tests across the public comparison selections passed.
• npm run check, npm run docs:check and npm run verify:test-discovery passed; 1,287 test files discovered exactly once. On final head 4121cfa, current-main static checks, docs checks and the six actual-file CLI/SDK comparisons all passed again.

Real program/provider evidence: a local HTTP redirect/fetch application in Chromium 153.0.8010.12, observed through the production CDP provider. Two recordings each retained two HTTP requests and one redirect; 200 → 201 was correctly reported as one metadata modification. A separately labelled derivative with one optional redirect type omitted returned unknown in both directions. An initial navigation attempt correctly returned target_changed; changing the probe to fixed-page fetches respected the inspection boundary. Browser/profile cleanup completed.

Those actual recordings and the labelled derivative passed six public CLI/real stdio SDK calls, including output-schema validation and unchanged source-file SHA-256 checks. No complete live-CDP inventory, native Windows/macOS execution or deep native provider coverage is claimed. The normalized fixture matrix and amplified benchmark are labelled synthetic.

Performance and context

Equivalent completed domain task with 10,000 synthetic repetitions of a genuine recorded API request: integration baseline first/warm comparisons 334 / 268–273 ms, updated 318 / 259–260 ms. Sampled peak process RSS 181 → 160 MiB; result JSON remained 2,136 bytes. Three samples are observations, not a statistical speedup claim. No persistent cache or new result fields were added.

Real public calls returned 3.7–3.8 KB CLI JSON; final warmed SDK calls took 9 ms after the first 113 ms call (the initial run was 11–13 / 160 ms). SDK full transport responses were 7.7–8.0 KB because they include text and structured content. Agent tokens were not measured. The existing one-time SDK catalog was measured separately at 3.09 MB initially and 3.17 MB after current main's schema changes and is outside this network-change scope.

Full related testing peaked at 2.05 GiB; static checks at 4.46 GiB; real Chromium at 1.10 GiB. No local guard stop or OOM.

Author readiness

Human owner: @N0zoM1z0

Recorded from the owner's explicit standing declarations for the remaining approved bug-fix batch. Technical review and executed evidence above were performed by the agent; ownership remains with the named human.

• 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.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new actionable defects were found.

Summary

Preserves uncertainty when passive network captures omit request types or inventory entries.

• Browser comparisons keep HTTP and WebSocket uncertainty separate.
• Unknown process configuration selections keep later reads uncertain.
• MCP schemas explain linked fields without unsupported dependency keywords.
• Regression checks keep existing CLI and MCP contracts clear.

Both earlier unnumbered findings are addressed: dropped requests now limit absence claims, and missing types no longer turn repeated requests into false modifications.

Reviewed the full PR because the merge-base checks differed. git diff --check passed; tests were not run. Whether another PR supersedes this one could not be checked because GitHub access was unavailable.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Supplied captures] --> B[Check HTTP inventory]
  A --> C[Check WebSocket inventory]
  A --> D[Find ambiguous request types]
  D --> E[Exclude ambiguous typed groups]
  E --> F[Compare known HTTP facts]
  B --> F
  C --> G[Compare WebSocket facts]
  F --> H{Proven difference?}
  G --> H
  H -->|Yes| I[Changed]
  H -->|No| J{All required facts complete?}
  J -->|Yes| K[Unchanged]
  J -->|No| L[Unknown]

Loading

_{Reviews (10) · Last reviewed commit: "chore: synchronize passive comparison re..." · Reviewed by Greptile}

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Try greploops.

[morluto]

Thanks for the careful work on #3082, @To3akaRin. The comparison now keeps proven HTTP additions visible while carrying uncertainty through missing metadata and incomplete HTTP or WebSocket coverage; that distinction makes the offline results much more useful to interpret. Great work tracing the edge cases back to the comparison owner.