[GH-ISSUE #5444] [Docs] Capture guide incorrectly says unsafe standard HAR numbers fail validation #3305

New issue

Closed

opened 2026-10-31 00:38:58 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:38:58 +00:00

Owner

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

Before submitting

I searched the existing issues for a related documentation report.
I removed credentials, tokens, private paths, and sensitive target data.

Documentation location

docs/web-network-captures.md, Reading the evidence, lines 252-256, in the numeric_literals bullet.

Problem

The guide says: "Unsafe standard HAR numeric fields fail schema validation; unsafe extension numbers remain available through their sidecars."

That blanket rejection statement is stale. An independent verifier ran the public inspect-web-network-capture command with the standard request.bodySize field set to the exact numeric lexeme 9007199254740993. The command exited 0, published reported.request.bodySize as null, and retained the exact lexeme in numeric_literals. Readers of the capture guide receive the wrong explanation of which HAR numbers the inspector admits. No runtime malfunction or evidence loss was observed.

Expected content

Proposed replacement wording:

Schema-valid HAR numbers are admitted even when they cannot be published safely as JSON numbers; those values are null in reported and their exact lexemes remain in numeric_literals. Standard numeric fields still must satisfy the pinned schema, including integer requirements judged from the numeric lexeme.

Keep the existing admission, exact-lexeme retention and null-publication behavior. The tests and historical change below establish this as intended behavior.

Supporting evidence

The independent verifier reproduced this on REA 6.7.0, source commit 074768901f3cdc8205b61773fb1faf6f6c7b3ca8, Node.js v26.12.0, macOS arm64, with dependencies installed and the CLI built. The synthetic fixture and output were isolated, with separate HOME and XDG roots. The relevant commands actually run were:

node --import tsx --input-type=module -e 'import { historicalHar } from "./tests/fixtures/historicalHar.ts"; import { writeFileSync } from "node:fs"; writeFileSync(process.argv[1], JSON.stringify(historicalHar()).replace(/"bodySize":0/, "\"bodySize\":9007199254740993"));' "$work/unsafe.har"
node scripts/rea.mjs inspect-web-network-capture "$work/unsafe.har" har --record 0 --format json > "$work/result.json"

Here $work is the verifier's isolated working directory. Replacing the number after serialization preserves the original numeric text. Observed result:

exit: 0
normalized_result.records[0].reported.request.bodySize: null
numeric_literals entry:
{"pointer":"/request/bodySize","producer_type":"json-number","literal":"9007199254740993"}

The verifier also observed acceptance with null publication and exact sidecars for response bodySize: 1e400 and entry time: 0.123456789012345678901. A control with response bodySize: 9007199254740993.5 exited 1 with invalid_request and HAR schema validation failed: type (must be integer).

Source-derived pinning evidence:

HarCapture.test.ts:293-315 pins acceptance of unsafe mandatory bodySize with null publication and an exact numeric sidecar.
HarCapture.test.ts:714-758 pins decimal/overflow acceptance and rejects fractional lexemes in integer fields. The verifier ran npm run test:local -- src/browser/history/HarCapture.test.ts; all 61 tests passed.
Commit 35e17a717, merged through #3159, deliberately separates schema admission from exact evidence publication. CHANGELOG.md:76 records that distinction.

Additional context

This report was prepared with AI assistance and independently reproduced by a separate verifier. The submitter checked current upstream main at 052956af3416fa01d93837e54fdec3ad2739f6d1: the stale passage remains, and the cited guide, decoder, tests and changelog have no changes after the verified baseline. Runtime results above belong to the baseline, not a new runtime run on current main.

Searches covered open and closed issues and PRs using command, symptom and module terms. #3145 and #3159 concern the earlier admission behavior and its implemented correction; they do not report the remaining stale guide sentence. This report requests only the documentation correction.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5444 ### Before submitting - [x] I searched the existing issues for a related documentation report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Documentation location [docs/web-network-captures.md, Reading the evidence, lines 252-256](https://github.com/morluto/rea/blob/074768901f3cdc8205b61773fb1faf6f6c7b3ca8/docs/web-network-captures.md#L252-L256), in the `numeric_literals` bullet. ### Problem The guide says: "Unsafe standard HAR numeric fields fail schema validation; unsafe extension numbers remain available through their sidecars." That blanket rejection statement is stale. An independent verifier ran the public `inspect-web-network-capture` command with the standard `request.bodySize` field set to the exact numeric lexeme `9007199254740993`. The command exited 0, published `reported.request.bodySize` as `null`, and retained the exact lexeme in `numeric_literals`. Readers of the capture guide receive the wrong explanation of which HAR numbers the inspector admits. No runtime malfunction or evidence loss was observed. ### Expected content Proposed replacement wording: > Schema-valid HAR numbers are admitted even when they cannot be published safely as JSON numbers; those values are null in reported and their exact lexemes remain in numeric_literals. Standard numeric fields still must satisfy the pinned schema, including integer requirements judged from the numeric lexeme. Keep the existing admission, exact-lexeme retention and null-publication behavior. The tests and historical change below establish this as intended behavior. ### Supporting evidence The independent verifier reproduced this on REA 6.7.0, source commit `074768901f3cdc8205b61773fb1faf6f6c7b3ca8`, Node.js v26.12.0, macOS arm64, with dependencies installed and the CLI built. The synthetic fixture and output were isolated, with separate HOME and XDG roots. The relevant commands actually run were: ```sh node --import tsx --input-type=module -e 'import { historicalHar } from "./tests/fixtures/historicalHar.ts"; import { writeFileSync } from "node:fs"; writeFileSync(process.argv[1], JSON.stringify(historicalHar()).replace(/"bodySize":0/, "\"bodySize\":9007199254740993"));' "$work/unsafe.har" node scripts/rea.mjs inspect-web-network-capture "$work/unsafe.har" har --record 0 --format json > "$work/result.json" ``` Here `$work` is the verifier's isolated working directory. Replacing the number after serialization preserves the original numeric text. Observed result: ```text exit: 0 normalized_result.records[0].reported.request.bodySize: null numeric_literals entry: {"pointer":"/request/bodySize","producer_type":"json-number","literal":"9007199254740993"} ``` The verifier also observed acceptance with null publication and exact sidecars for response `bodySize: 1e400` and entry `time: 0.123456789012345678901`. A control with response `bodySize: 9007199254740993.5` exited 1 with `invalid_request` and `HAR schema validation failed: type (must be integer).` Source-derived pinning evidence: - [HarCapture.test.ts:293-315](https://github.com/morluto/rea/blob/074768901f3cdc8205b61773fb1faf6f6c7b3ca8/src/browser/history/HarCapture.test.ts#L293-L315) pins acceptance of unsafe mandatory `bodySize` with null publication and an exact numeric sidecar. - [HarCapture.test.ts:714-758](https://github.com/morluto/rea/blob/074768901f3cdc8205b61773fb1faf6f6c7b3ca8/src/browser/history/HarCapture.test.ts#L714-L758) pins decimal/overflow acceptance and rejects fractional lexemes in integer fields. The verifier ran `npm run test:local -- src/browser/history/HarCapture.test.ts`; all 61 tests passed. - [Commit 35e17a717](https://github.com/morluto/rea/commit/35e17a717229c1905828c0a0664a1825a985cf28), merged through [#3159](https://github.com/morluto/rea/pull/3159), deliberately separates schema admission from exact evidence publication. [CHANGELOG.md:76](https://github.com/morluto/rea/blob/074768901f3cdc8205b61773fb1faf6f6c7b3ca8/CHANGELOG.md#L76) records that distinction. ### Additional context This report was prepared with AI assistance and independently reproduced by a separate verifier. The submitter checked current upstream `main` at `052956af3416fa01d93837e54fdec3ad2739f6d1`: the stale passage remains, and the cited guide, decoder, tests and changelog have no changes after the verified baseline. Runtime results above belong to the baseline, not a new runtime run on current main. Searches covered open and closed issues and PRs using command, symptom and module terms. #3145 and #3159 concern the earlier admission behavior and its implemented correction; they do not report the remaining stale guide sentence. This report requests only the documentation correction.

bsakaguchi closed this issue

2026-10-31 00:38:59 +00:00

bsakaguchi commented

2026-10-31 00:38:59 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 24, 2026):

Checked the reported fix on main at d87e73f2db.

The stale blanket rejection statement is gone. The numeric_literals bullet now says schema-valid HAR numbers are admitted even if not safely publishable, nulls represent them in reported, exact lexemes remain in numeric_literals, and integer requirements are judged from the lexeme. This matches the requested text and existing decoder semantics.

Implementation: web-network-captures.md, HarCapture.test.ts.

The relevant regression checks in HarCapture.test.ts passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

@coygeek commented on GitHub (Oct 24, 2026): Checked the reported fix on `main` at d87e73f2db50be72d33a4b3c7199af35518b441c. The stale blanket rejection statement is gone. The numeric_literals bullet now says schema-valid HAR numbers are admitted even if not safely publishable, nulls represent them in reported, exact lexemes remain in numeric_literals, and integer requirements are judged from the lexeme. This matches the requested text and existing decoder semantics. Implementation: [web-network-captures.md](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/docs/web-network-captures.md#L307), [HarCapture.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/browser/history/HarCapture.test.ts#L575). The relevant regression checks in [HarCapture.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/browser/history/HarCapture.test.ts) passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

bsakaguchi referenced this issue

2026-10-31 00:39:08 +00:00

[GH-ISSUE #5462] [Bug] Native inspection admits universal static archives as Mach-O images #3320

bsakaguchi referenced this issue

2026-10-31 01:08:52 +00:00

[PR #3305] [CLOSED] fix(apple): stop JVM class lookalikes passing as FAT Mach-O #5715