[GH-ISSUE #2627] fix(browser): preserve recovered parse uncertainty in bundle results #944

New issue

Closed

opened 2026-10-15 18:29:47 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:29:47 +00:00

Owner

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

Summary

Bundle analysis labels a recovered JavaScript parse as complete and returns no parse-gap explanation. The same captured text through the shared source analyzer exposes the recovered syntax error and reports partial analysis. Useful endpoint evidence is retained, but the bundle result overstates parse coverage.

Steps to reproduce

At the source baseline below, use the single-script inspection fixture in src/domain/webBundleAnalyzer.test.ts with source let x; let x; fetch('/partial');.
Call analyzeCapturedWebBundle and inspect completeness, unknowns, and endpoint candidates.
Run analyzeJavaScriptStaticSource on the same text and inspect parse_status and parse_error_count as a recovery-aware control.

Expected behavior

Analysis of captured text should retain uncertainty when the parser recovers from a syntax error. The bundle result should report partial parse coverage and expose a meaningful recovery reason while preserving usable findings. Captured malformed source need not be executable to receive this supported partial-analysis outcome.

Actual behavior

The observed bundle result reported status: "complete", parse_failures: 0, and no unknowns, while retaining /partial. The shared source analyzer reported parse_status: "partial" and parse_error_count: 1. A valid fetch control was complete, and function broken( { produced partial bundle analysis with one parse failure.

Evidence

Expected source: AGENTS.md, Architecture and Cleanup, requires meaningful failure reasons and preserved uncertainty; src/domain/javascript/javascriptStaticAnalysis.ts:135-170 explicitly treats recovered syntax errors as partial facts; src/domain/webBundleAnalysis.ts:218-223 exposes bundle completeness.
Failure source: src/domain/webBundleAnalyzerInspection.ts:60-73 enables parser recovery but only counts thrown failures; src/domain/webBundleAnalyzerResult.ts:184-191 consequently reports complete coverage for the recovered input.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

A focused domain observation test passed while asserting the faulty bundle result, the shared analyzer's recovered-error result, and the valid and hard-failure controls. Verification used the production source functions and a schema-validated page inspection, without a live browser or CLI capture.

Restoration check

For the duplicate declaration source, report partial parse coverage with an observable recovery explanation and retain /partial. Keep valid source complete and hard parse failures partial. The recovered-error representation may differ from the thrown-failure count, provided callers can identify the incomplete parse accurately.

Runtime or environment

Source revision: 8b181716ac. Node.js v26.10.0, npm 11.19.1, and lockfile-installed dependencies.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: A reachable class of captured malformed sources produces misleading completeness metadata. The bounded probe did not establish loss of the retained endpoint or a downstream consumer failure.
Workaround status: unverified
Workaround basis: The shared source-analysis control identifies the recovered error, but a practical user-facing workflow for checking captured bundle artifacts separately was not verified.

Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2627 ## Summary Bundle analysis labels a recovered JavaScript parse as complete and returns no parse-gap explanation. The same captured text through the shared source analyzer exposes the recovered syntax error and reports partial analysis. Useful endpoint evidence is retained, but the bundle result overstates parse coverage. ## Steps to reproduce 1. At the source baseline below, use the single-script inspection fixture in `src/domain/webBundleAnalyzer.test.ts` with source `let x; let x; fetch('/partial');`. 2. Call `analyzeCapturedWebBundle` and inspect `completeness`, `unknowns`, and endpoint candidates. 3. Run `analyzeJavaScriptStaticSource` on the same text and inspect `parse_status` and `parse_error_count` as a recovery-aware control. ## Expected behavior Analysis of captured text should retain uncertainty when the parser recovers from a syntax error. The bundle result should report partial parse coverage and expose a meaningful recovery reason while preserving usable findings. Captured malformed source need not be executable to receive this supported partial-analysis outcome. ## Actual behavior The observed bundle result reported `status: "complete"`, `parse_failures: 0`, and no unknowns, while retaining `/partial`. The shared source analyzer reported `parse_status: "partial"` and `parse_error_count: 1`. A valid fetch control was complete, and `function broken( {` produced partial bundle analysis with one parse failure. ## Evidence - Expected source: `AGENTS.md`, Architecture and Cleanup, requires meaningful failure reasons and preserved uncertainty; `src/domain/javascript/javascriptStaticAnalysis.ts:135-170` explicitly treats recovered syntax errors as partial facts; `src/domain/webBundleAnalysis.ts:218-223` exposes bundle completeness. - Failure source: `src/domain/webBundleAnalyzerInspection.ts:60-73` enables parser recovery but only counts thrown failures; `src/domain/webBundleAnalyzerResult.ts:184-191` consequently reports complete coverage for the recovered input. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete A focused domain observation test passed while asserting the faulty bundle result, the shared analyzer's recovered-error result, and the valid and hard-failure controls. Verification used the production source functions and a schema-validated page inspection, without a live browser or CLI capture. ## Restoration check For the duplicate declaration source, report partial parse coverage with an observable recovery explanation and retain `/partial`. Keep valid source complete and hard parse failures partial. The recovered-error representation may differ from the thrown-failure count, provided callers can identify the incomplete parse accurately. ## Runtime or environment Source revision: 8b181716aca2cb467be499cba226abfb5ae19141. Node.js v26.10.0, npm 11.19.1, and lockfile-installed dependencies. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: A reachable class of captured malformed sources produces misleading completeness metadata. The bounded probe did not establish loss of the retained endpoint or a downstream consumer failure. - Workaround status: unverified - Workaround basis: The shared source-analysis control identifies the recovered error, but a practical user-facing workflow for checking captured bundle artifacts separately was not verified.

bsakaguchi

2026-10-15 18:29:47 +00:00

closed this issue
added the
bug
label

bsakaguchi referenced this issue

2026-10-17 21:07:07 +00:00

[PR #944] [MERGED] fix(native-ui): handle incomplete accessibility child collections #2522

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

No description provided.

Rows
Columns