morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #7132] [Bug] trace_web_source_location reports an out-of-range generated_position as invalid_format without bounds #4283

New issue

Open

opened 2026-10-31 00:48:30 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-31 00:48:30 +00:00

Owner

Originally created by @amyanger on GitHub (Oct 25, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7132

Before submitting

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

Area

CLI

Observed behavior

trace-web-source-location (MCP trace_web_source_location) given a well-formed generated_position past the end of the selected script reports an invalid_format issue on ["generated_position"] with no bounds. The coordinates are valid integers; they only fall outside the retained script, so the caller is told its input is malformed and is not told which coordinate to change or what range is valid.

This is the same selection-fault shape that #6979 fixed for export_web_scripts script_index and #7067 fixed for record_ordinals.

Reproduction

Ran on macOS arm64, Node 24.22.1, at upstream/main fc43e285e, through the built CLI. The manifest, script and map are the webSourceLocationFixture used by tests/acceptance/webSourceLocationCli.test.ts: one script whose text is generated (one line, 9 UTF-16 code units) and a one-segment map.

rea trace-web-source-location <dir>/manifest.json 0 <dir>/app.js.map 'https://app.test/app.js.map?v=1#context' 1 0 --json    # exit 0, generated_offset 0
rea trace-web-source-location <dir>/manifest.json 0 <dir>/app.js.map 'https://app.test/app.js.map?v=1#context' 2 0 --json    # exit 1
rea trace-web-source-location <dir>/manifest.json 0 <dir>/app.js.map 'https://app.test/app.js.map?v=1#context' 1 999 --json  # exit 1

Both failing calls return the same issue.

Expected behavior

An out_of_range issue on the coordinate that is past the end, with the valid bounds, as export_web_scripts and inspect_web_network_capture now report for their selections:

line past the last line: path ["generated_position","line"], minimum: 1, maximum: <last line>
column past the end of its line: path ["generated_position","column"], minimum: 0, maximum: <that line's UTF-16 length>

Impact and scope

Agents correct requests from the issue reason, path and bounds. invalid_format on the whole object suggests rewriting the position, and gives no range to pick from. Observed through the CLI; MCP uses the same service and projection (source-derived).

REA version

6.8.0, revision fc43e285e

Runtime and platform

macOS 27.0.1 arm64, Node 24.22.1

Target and artifact context

An export_web_scripts manifest with one exported script and a caller-selected source map (test fixture).

Interface

CLI

Earliest failure stage

Request parsing or validation

Relevant output or evidence

code and details.issues from the CLI --json output for 2 0 and 1 999, other fields trimmed:

{"code":"invalid_request","details":{"issues":[{"path":["generated_position"],"reason":"invalid_format","message":"Selected generated position is outside the retained script text (one-based lines; zero-based UTF-16 columns)."}]}}

Analysis or suspected cause

Source-derived: verifyPairing in src/application/WebSourceLocationService.ts sends the out-of-range result of webSourceOffset through the file's invalid() helper, which hard-codes reason: "invalid_format" for every rejection.

Originally created by @amyanger on GitHub (Oct 25, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7132 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area CLI ### Observed behavior `trace-web-source-location` (MCP `trace_web_source_location`) given a well-formed `generated_position` past the end of the selected script reports an `invalid_format` issue on `["generated_position"]` with no bounds. The coordinates are valid integers; they only fall outside the retained script, so the caller is told its input is malformed and is not told which coordinate to change or what range is valid. This is the same selection-fault shape that #6979 fixed for `export_web_scripts` `script_index` and #7067 fixed for `record_ordinals`. ### Reproduction Ran on macOS arm64, Node 24.22.1, at upstream/main `fc43e285e`, through the built CLI. The manifest, script and map are the `webSourceLocationFixture` used by `tests/acceptance/webSourceLocationCli.test.ts`: one script whose text is `generated` (one line, 9 UTF-16 code units) and a one-segment map. ```sh rea trace-web-source-location <dir>/manifest.json 0 <dir>/app.js.map 'https://app.test/app.js.map?v=1#context' 1 0 --json # exit 0, generated_offset 0 rea trace-web-source-location <dir>/manifest.json 0 <dir>/app.js.map 'https://app.test/app.js.map?v=1#context' 2 0 --json # exit 1 rea trace-web-source-location <dir>/manifest.json 0 <dir>/app.js.map 'https://app.test/app.js.map?v=1#context' 1 999 --json # exit 1 ``` Both failing calls return the same issue. ### Expected behavior An `out_of_range` issue on the coordinate that is past the end, with the valid bounds, as `export_web_scripts` and `inspect_web_network_capture` now report for their selections: - line past the last line: path `["generated_position","line"]`, `minimum: 1`, `maximum: <last line>` - column past the end of its line: path `["generated_position","column"]`, `minimum: 0`, `maximum: <that line's UTF-16 length>` ### Impact and scope Agents correct requests from the issue reason, path and bounds. `invalid_format` on the whole object suggests rewriting the position, and gives no range to pick from. Observed through the CLI; MCP uses the same service and projection (source-derived). ### REA version 6.8.0, revision `fc43e285e` ### Runtime and platform macOS 27.0.1 arm64, Node 24.22.1 ### Target and artifact context An `export_web_scripts` manifest with one exported script and a caller-selected source map (test fixture). ### Interface CLI ### Earliest failure stage Request parsing or validation ### Relevant output or evidence `code` and `details.issues` from the CLI `--json` output for `2 0` and `1 999`, other fields trimmed: ```json {"code":"invalid_request","details":{"issues":[{"path":["generated_position"],"reason":"invalid_format","message":"Selected generated position is outside the retained script text (one-based lines; zero-based UTF-16 columns)."}]}} ``` ### Analysis or suspected cause Source-derived: `verifyPairing` in `src/application/WebSourceLocationService.ts` sends the out-of-range result of `webSourceOffset` through the file's `invalid()` helper, which hard-codes `reason: "invalid_format"` for every rejection.

bsakaguchi commented

2026-10-31 00:48:31 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 25, 2026):

Agree with the direction of reporting this as a selection fault instead of invalid_format. One suggestion: when the position is out of range, including the actual valid bounds in the error message would make it much easier for callers to diagnose why the pairing check failed (e.g. the generated position vs. the source length). Nice to see this handled before release.

@XinwangTao commented on GitHub (Oct 25, 2026): Agree with the direction of reporting this as a selection fault instead of invalid_format. One suggestion: when the position is out of range, including the actual valid bounds in the error message would make it much easier for callers to diagnose why the pairing check failed (e.g. the generated position vs. the source length). Nice to see this handled before release.

bsakaguchi commented

2026-10-31 00:48:31 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 25, 2026):

Same fault shape as #6979/#7067 as you noted — the fix should mirror them: keep the format validation (well-formed integers) separate from range validation, and report an out_of_range-style error that states the offending coordinate and the valid interval (e.g. 0 <= generated_position < script.length) instead of claiming invalid_format. That keeps callers able to correct their input rather than guessing. Also consider including the actual script length in the error payload so tools can adjust automatically.

@XinwangTao commented on GitHub (Oct 25, 2026): Same fault shape as #6979/#7067 as you noted — the fix should mirror them: keep the format validation (well-formed integers) separate from range validation, and report an out_of_range-style error that states the offending coordinate and the valid interval (e.g. 0 <= generated_position < script.length) instead of claiming invalid_format. That keeps callers able to correct their input rather than guessing. Also consider including the actual script length in the error payload so tools can adjust automatically.

bsakaguchi commented

2026-10-31 00:48:31 +00:00

Author

Owner

@amyanger commented on GitHub (Oct 26, 2026):

Thanks for the review. Draft PR #7133 does both of these. Malformed coordinates keep the existing invalid-input error. A well-formed position past the end of the retained script now returns out_of_range on generated_position.line or generated_position.column, with minimum and maximum in the issue and a message giving the last valid line or column, for example "No line 5; the retained script ends at line 1 (one-based lines)." It follows the same pattern as #6979 and #7067.

The bounds are line and column, not a single offset into script.length, because callers send line/column pairs. A line count and a per-line column limit tell them directly what to fix.

The PR is still a draft. I'm updating it for recent changes on main before it goes up for review.

@amyanger commented on GitHub (Oct 26, 2026): Thanks for the review. Draft PR #7133 does both of these. Malformed coordinates keep the existing invalid-input error. A well-formed position past the end of the retained script now returns `out_of_range` on `generated_position.line` or `generated_position.column`, with `minimum` and `maximum` in the issue and a message giving the last valid line or column, for example "No line 5; the retained script ends at line 1 (one-based lines)." It follows the same pattern as #6979 and #7067. The bounds are line and column, not a single offset into `script.length`, because callers send line/column pairs. A line count and a per-line column limit tell them directly what to fix. The PR is still a draft. I'm updating it for recent changes on main before it goes up for review.

bsakaguchi referenced this issue

2026-10-31 01:12:18 +00:00

[PR #4283] [CLOSED] feat(mcp): add native vulnerability review prompt #6158

bsakaguchi referenced this issue

2026-11-01 21:10:57 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

bsakaguchi referenced this issue

2026-11-01 21:11:07 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425