[GH-ISSUE #3251] fix(domain): stop invalid JSON before Evidence authentication #1165

New issue

Closed

opened 2026-10-15 18:31:40 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

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

Originally assigned to: @N0zoM1z0 on GitHub.

Invalid JSON is rejected by the JSON schema but can still reach Evidence authentication. This both invokes caller-controlled getters after rejecting them and replaces the documented nesting-limit diagnostic with a stack overflow for deeply nested input.

Baseline: main 7375ab6e34e511095a74d5a67e57cec28d56fd10, after the independent inert-JSON change f79fd59e9 and catalog projection fix ee9bf58ab. This is independent of compiler-cache PR #3227, whose effective changes are compiler inputs, CI selection and their tests.

Reproductions use the actual built jsonValueSchema, parseEvidence, and the current valid INVESTIGATION_EXAMPLES.compare_process_captures.input.left record:

const baseline = INVESTIGATION_EXAMPLES.compare_process_captures.input.left;
parseEvidence(baseline); // valid production example succeeds
let reads = 0;
const parameters = { get attack() { reads++; return "observed"; } };
jsonValueSchema.safeParse(parameters); // rejected; reads === 0
parseEvidence({ ...baseline, parameters }); // throws ZodError; reads === 3

The second rejection contains both JSON objects cannot contain accessors and an Evidence semantic-identifier mismatch. The getter reads happen in the subsequent canonical digest, although the JSON admission step already rejected this object.

For a separate actual CLI control, tests/boundary/process/processCli.test.ts / reports the JSON depth constraint through the compiled comparison CLI fails on Linux and in the hosted macOS Apple lane (job 115711031620, run 38520960964). A 10,000-level input is rejected as invalid_input, but the error says Maximum call stack size exceeded rather than the documented maximum nesting depth. Direct jsonValueValidationIssue and jsonValueSchema.safeParse correctly report the 1,000-level limit. Direct parseEvidence instead throws RangeError from recursive emitCanonical calls.

Root cause: JSON admission now adds a continuable custom issue in its superRefine. Parent Evidence refinements therefore still run on JSON that failed admission. The semantic-ID refinement recursively canonicalizes that inadmissible value. This is an integration defect in validation continuation, not a reason to remove the CLI assertion or accept getters.

Correct at the owning JSON boundary by making failed JSON admission noncontinuable while retaining one validation traversal. Preserve the original rejection reason and field path; valid values must still undergo semantic-ID verification. Do not add a downstream catch that masks the unexpected canonicalization, loosen getter/proxy/array checks, or recursively stringify an untrusted value as a fallback.

Validation should exercise actual Evidence composition with getter/proxy side-effect counters, deeply nested input, valid and mismatched semantic IDs, and the existing compiled CLI negative control. Re-run relevant JSON/Evidence consumers and production stdio MCP/application flows. Measure representative healthy parsing/workflows and invalid-input handling with explicit toolchain, source, CPU, elapsed time and process-family memory limits; avoiding work on rejected data is not evidence of a general application speedup.

Originally created by @N0zoM1z0 on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3251 Originally assigned to: @N0zoM1z0 on GitHub. Invalid JSON is rejected by the JSON schema but can still reach Evidence authentication. This both invokes caller-controlled getters after rejecting them and replaces the documented nesting-limit diagnostic with a stack overflow for deeply nested input. Baseline: main `7375ab6e34e511095a74d5a67e57cec28d56fd10`, after the independent inert-JSON change `f79fd59e9` and catalog projection fix `ee9bf58ab`. This is independent of compiler-cache PR #3227, whose effective changes are compiler inputs, CI selection and their tests. Reproductions use the actual built `jsonValueSchema`, `parseEvidence`, and the current valid `INVESTIGATION_EXAMPLES.compare_process_captures.input.left` record: ```js const baseline = INVESTIGATION_EXAMPLES.compare_process_captures.input.left; parseEvidence(baseline); // valid production example succeeds let reads = 0; const parameters = { get attack() { reads++; return "observed"; } }; jsonValueSchema.safeParse(parameters); // rejected; reads === 0 parseEvidence({ ...baseline, parameters }); // throws ZodError; reads === 3 ``` The second rejection contains both `JSON objects cannot contain accessors` and an Evidence semantic-identifier mismatch. The getter reads happen in the subsequent canonical digest, although the JSON admission step already rejected this object. For a separate actual CLI control, `tests/boundary/process/processCli.test.ts` / `reports the JSON depth constraint through the compiled comparison CLI` fails on Linux and in the hosted macOS Apple lane (job `115711031620`, run [38520960964](https://github.com/morluto/rea/actions/runs/38520960964)). A 10,000-level input is rejected as `invalid_input`, but the error says `Maximum call stack size exceeded` rather than the documented maximum nesting depth. Direct `jsonValueValidationIssue` and `jsonValueSchema.safeParse` correctly report the 1,000-level limit. Direct `parseEvidence` instead throws `RangeError` from recursive `emitCanonical` calls. Root cause: JSON admission now adds a continuable custom issue in its `superRefine`. Parent Evidence refinements therefore still run on JSON that failed admission. The semantic-ID refinement recursively canonicalizes that inadmissible value. This is an integration defect in validation continuation, not a reason to remove the CLI assertion or accept getters. Correct at the owning JSON boundary by making failed JSON admission noncontinuable while retaining one validation traversal. Preserve the original rejection reason and field path; valid values must still undergo semantic-ID verification. Do not add a downstream catch that masks the unexpected canonicalization, loosen getter/proxy/array checks, or recursively stringify an untrusted value as a fallback. Validation should exercise actual Evidence composition with getter/proxy side-effect counters, deeply nested input, valid and mismatched semantic IDs, and the existing compiled CLI negative control. Re-run relevant JSON/Evidence consumers and production stdio MCP/application flows. Measure representative healthy parsing/workflows and invalid-input handling with explicit toolchain, source, CPU, elapsed time and process-family memory limits; avoiding work on rejected data is not evidence of a general application speedup.

bsakaguchi

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

closed this issue
added the
bug
label

bsakaguchi referenced this issue

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

[PR #1182] [MERGED] fix(doctor): find the Homebrew Hopper cask without writing Homebrew caches #2705

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#1165

No description provided.

Rows
Columns