[GH-ISSUE #3145] Question: lossless admission outside the documented safe-number HAR profile #1097

New issue

Closed

opened 2026-10-15 18:31:02 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:31:02 +00:00

Owner

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

This is a support-policy clarification, not a confirmed defect in the currently documented profile.

After the public reproduction, the related suite exposed the explicit existing guard keeps unsafe extension numeric lexemes and rejects unsafe mandatory schema numbers. The guide also states in docs/web-network-captures.md that unsafe standard HAR numeric fields fail schema validation, while unsafe extension numbers remain in their sidecars. I missed that support restriction when filing this issue.

The observation is reproducible on main 58300885207133422af235e0f2b10658cf958b03: a synthetic HAR 1.2 time: 0.123456789012345678901 or bodySize: 9007199254740993 is rejected by the public CLI, although the pinned validator accepts ordinary JSON.parse projections. Ordinary values pass. This matches the documented REA restriction; it does not by itself justify a bug-fix PR.

The experimental validation-only change admits those inputs and retains exact numeric sidecars/unknown reported values, but fails the existing intentional rejection guard. It has not been committed, pushed or submitted as a PR. A naive Number conversion also needs careful treatment of exact integer/minimum constraints; accepting rounded invalid input would be inappropriate.

Question for maintainers: should this documented safe-number admission restriction remain, or should lossless numeric sidecars eventually allow more standard fields? Until that scope is decided and fully verified, I am keeping the experiment local. This issue is not counted as a verified bug contribution.

Originally created by @xu91102 on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3145 This is a support-policy clarification, not a confirmed defect in the currently documented profile. After the public reproduction, the related suite exposed the explicit existing guard `keeps unsafe extension numeric lexemes and rejects unsafe mandatory schema numbers`. The guide also states in `docs/web-network-captures.md` that unsafe standard HAR numeric fields fail schema validation, while unsafe extension numbers remain in their sidecars. I missed that support restriction when filing this issue. The observation is reproducible on main `58300885207133422af235e0f2b10658cf958b03`: a synthetic HAR 1.2 `time: 0.123456789012345678901` or `bodySize: 9007199254740993` is rejected by the public CLI, although the pinned validator accepts ordinary JSON.parse projections. Ordinary values pass. This matches the documented REA restriction; it does not by itself justify a bug-fix PR. The experimental validation-only change admits those inputs and retains exact numeric sidecars/unknown reported values, but fails the existing intentional rejection guard. It has not been committed, pushed or submitted as a PR. A naive Number conversion also needs careful treatment of exact integer/minimum constraints; accepting rounded invalid input would be inappropriate. Question for maintainers: should this documented safe-number admission restriction remain, or should lossless numeric sidecars eventually allow more standard fields? Until that scope is decided and fully verified, I am keeping the experiment local. This issue is not counted as a verified bug contribution.

bsakaguchi

2026-10-15 18:31:02 +00:00

closed this issue
added the
question
label

bsakaguchi commented

2026-10-15 18:31:03 +00:00

Author

Owner

@z2Ace0107 commented on GitHub (Oct 14, 2026):

I'd like to work on a focused fix for this issue. I reproduced both the high-precision decimal and unsafe-integer cases on revision 583008852 with Node 24.18.0: the pinned HAR validator accepts them, while decodeHarCapture rejects them. The ordinary-value control passes.

I'll separate validation from evidence-number projection, preserve exact numeric lexemes and explicit unknown values, and retain malformed-input and redaction checks. I'll recheck current main and coordinate with the adjacent changes in #2872 before implementation.

@z2Ace0107 commented on GitHub (Oct 14, 2026): I'd like to work on a focused fix for this issue. I reproduced both the high-precision decimal and unsafe-integer cases on revision `583008852` with Node 24.18.0: the pinned HAR validator accepts them, while `decodeHarCapture` rejects them. The ordinary-value control passes. I'll separate validation from evidence-number projection, preserve exact numeric lexemes and explicit unknown values, and retain malformed-input and redaction checks. I'll recheck current main and coordinate with the adjacent changes in #2872 before implementation.

bsakaguchi referenced this issue

2026-10-17 21:08:35 +00:00

[PR #1097] [MERGED] fix(browser): treat module-import initiator positions as script positions #2646

bsakaguchi referenced this issue

2026-10-17 21:09:05 +00:00

[PR #1155] [MERGED] fix(artifacts): recheck failed DMG detaches before reporting cleanup failure #2689