morluto/rea

Fork 0

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

[GH-ISSUE #7168] [Bug] Full-profile capture_browser_scenario patterns fail v-mode compilation, and one uses a look-ahead #4292

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

MCP or agent integration

Observed behavior

With REA_MCP_INPUT_SCHEMA_PROFILE=full, the request action of capture_browser_scenario advertises two patterns that Unicode-set (v) mode rejects. Both compile under Annex B and u, and the default compact catalog does not advertise them.

actions[].path: ^\/(?![/\\]) (src/domain/browserScenarioValues.ts:322). The unescaped / inside the class fails in v mode. The pattern is also a look-ahead, which advertisedPatternsVMode.test.ts excludes because RE2 and Rust validators reject look-around.
actions[].headers[].name: ^[!#$%&'*+.^_`|~0-9A-Za-z-]+$ (line 144). In v mode, | and the trailing - are class syntax characters.

Reproduction

Start rea mcp with REA_MCP_INPUT_SCHEMA_PROFILE=full (6.8.0, or a source build of 447907f28).
Call tools/list and compile the capture_browser_scenario patterns with new RegExp(pattern, "v").
Alternatively, run new RegExp(String.raw`^\/(?![/\\])`, "v") directly; it throws Invalid character in character class.

Expected behavior

In both profiles, advertised patterns compile in Annex B, u and v modes and contain no look-around, while accepting the same strings.

Impact and scope

A client that compiles advertised patterns in v mode (#1581) or validates them with RE2 or Rust (#1212) rejects the complete tools request when REA uses the full profile, before any tool executes. This applies on any host; the default compact profile is unaffected. It is the same compatibility boundary as #1212, #1581 and #7151.

REA version

6.8.0 (the published package's dist/domain/browserScenarioValues.js has both patterns) and source at 447907f28; the source lines are unchanged at 1173c0a9d

Runtime and platform

Node 24.22.1; Windows 11 Pro x64 (10.0.26300). The patterns do not depend on the host (source-derived).

Target and artifact context

Not applicable: only tools/list is needed.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Compiling every pattern that the built server advertises over stdio, with REA_MCP_INPUT_SCHEMA_PROFILE=full (the 56 Windows-only path entries from #7151 are left out):

capture_browser_scenario inputSchema/properties/actions/items/oneOf[7]/properties/path/pattern /^\/(?![/\\])/v: Invalid character in character class
capture_browser_scenario inputSchema/properties/actions/items/oneOf[7]/properties/headers/items/properties/name/pattern /^[!#$%&'*+.^_`|~0-9A-Za-z-]+$/v: Invalid character in character class

Typed outcome or recovery expected

Not applicable: the catalog should be accepted.

Analysis or suspected cause

Source-derived: both patterns came in with #6946. advertisedPatternsVMode.test.ts builds the server with the default profile, which is compact, so patterns that only the full profile advertises are not checked. This is the same gap noted in #7151, and running that test for the full profile would catch them.

A possible spelling uses hex escapes, as line 209 of the same file already does with \x2d and \x2f:

header name: ^[!#$%&'*+.^_`\x7C~0-9A-Za-z\x2D]+$
request path: ^\x2F(?:[^\x2F\x5C]|$)

I checked both candidates locally. They compile in all three modes, contain no look-around, and give the same results as the current patterns on 41,371 and 1,555 generated strings respectively.

Additional context

I found these while checking #7151, whose full-profile scan lists them. The open draft #7162 carries the same request-path pattern into a new schema.

Originally created by @pablodiazjorge on GitHub (Oct 25, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7168 ### 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 MCP or agent integration ### Observed behavior With `REA_MCP_INPUT_SCHEMA_PROFILE=full`, the `request` action of `capture_browser_scenario` advertises two patterns that Unicode-set (`v`) mode rejects. Both compile under Annex B and `u`, and the default compact catalog does not advertise them. - `actions[].path`: `^\/(?![/\\])` (`src/domain/browserScenarioValues.ts:322`). The unescaped `/` inside the class fails in `v` mode. The pattern is also a look-ahead, which `advertisedPatternsVMode.test.ts` excludes because RE2 and Rust validators reject look-around. - `actions[].headers[].name`: ``^[!#$%&'*+.^_`|~0-9A-Za-z-]+$`` (line 144). In `v` mode, `|` and the trailing `-` are class syntax characters. ### Reproduction 1. Start `rea mcp` with `REA_MCP_INPUT_SCHEMA_PROFILE=full` (6.8.0, or a source build of `447907f28`). 2. Call `tools/list` and compile the `capture_browser_scenario` patterns with `new RegExp(pattern, "v")`. 3. Alternatively, run ``new RegExp(String.raw`^\/(?![/\\])`, "v")`` directly; it throws `Invalid character in character class`. ### Expected behavior In both profiles, advertised patterns compile in Annex B, `u` and `v` modes and contain no look-around, while accepting the same strings. ### Impact and scope A client that compiles advertised patterns in `v` mode (#1581) or validates them with RE2 or Rust (#1212) rejects the complete tools request when REA uses the full profile, before any tool executes. This applies on any host; the default compact profile is unaffected. It is the same compatibility boundary as #1212, #1581 and #7151. ### REA version 6.8.0 (the published package's `dist/domain/browserScenarioValues.js` has both patterns) and source at `447907f28`; the source lines are unchanged at `1173c0a9d` ### Runtime and platform Node 24.22.1; Windows 11 Pro x64 (10.0.26300). The patterns do not depend on the host (source-derived). ### Target and artifact context Not applicable: only `tools/list` is needed. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence Compiling every pattern that the built server advertises over stdio, with `REA_MCP_INPUT_SCHEMA_PROFILE=full` (the 56 Windows-only path entries from #7151 are left out): ```text capture_browser_scenario inputSchema/properties/actions/items/oneOf[7]/properties/path/pattern /^\/(?![/\\])/v: Invalid character in character class capture_browser_scenario inputSchema/properties/actions/items/oneOf[7]/properties/headers/items/properties/name/pattern /^[!#$%&'*+.^_`|~0-9A-Za-z-]+$/v: Invalid character in character class ``` ### Typed outcome or recovery expected Not applicable: the catalog should be accepted. ### Analysis or suspected cause Source-derived: both patterns came in with #6946. `advertisedPatternsVMode.test.ts` builds the server with the default profile, which is compact, so patterns that only the full profile advertises are not checked. This is the same gap noted in #7151, and running that test for the full profile would catch them. A possible spelling uses hex escapes, as line 209 of the same file already does with `\x2d` and `\x2f`: - header name: ``^[!#$%&'*+.^_`\x7C~0-9A-Za-z\x2D]+$`` - request path: `^\x2F(?:[^\x2F\x5C]|$)` I checked both candidates locally. They compile in all three modes, contain no look-around, and give the same results as the current patterns on 41,371 and 1,555 generated strings respectively. ### Additional context I found these while checking #7151, whose full-profile scan lists them. The open draft #7162 carries the same request-path pattern into a new schema.

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

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

Hi @pablodiazjorge, I’d like to work on this issue if it’s still available.

I went through the report and my understanding is that the full MCP input-schema profile currently exposes two capture_browser_scenario patterns that are valid under the existing JavaScript regex modes but fail under v mode, with the request-path pattern also relying on look-ahead that is incompatible with RE2/Rust-style validators.

I’d first reproduce the failures from tools/list on current main, then verify equivalent portable pattern forms preserve the existing accepted/rejected inputs. I’d also extend the advertised-pattern regression coverage so both compact and full profiles are checked, including the existing no-lookaround portability requirement.

If that scope matches the intended fix, I’d be happy to take it.

@DevyanshMalhotra commented on GitHub (Oct 26, 2026): Hi @pablodiazjorge, I’d like to work on this issue if it’s still available. I went through the report and my understanding is that the full MCP input-schema profile currently exposes two `capture_browser_scenario` patterns that are valid under the existing JavaScript regex modes but fail under `v` mode, with the request-path pattern also relying on look-ahead that is incompatible with RE2/Rust-style validators. I’d first reproduce the failures from `tools/list` on current `main`, then verify equivalent portable pattern forms preserve the existing accepted/rejected inputs. I’d also extend the advertised-pattern regression coverage so both compact and full profiles are checked, including the existing no-lookaround portability requirement. If that scope matches the intended fix, I’d be happy to take it.

bsakaguchi commented

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

Author

Owner

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

Thanks for the interest. I'm not a maintainer, so I can't assign it, and two PRs already target this issue: #7191 and the draft #7185. Reviewing or testing one of them is probably the most useful next step, and the maintainers will choose the fix.

@pablodiazjorge commented on GitHub (Oct 26, 2026): Thanks for the interest. I'm not a maintainer, so I can't assign it, and two PRs already target this issue: #7191 and the draft #7185. Reviewing or testing one of them is probably the most useful next step, and the maintainers will choose the fix.

bsakaguchi commented

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

Author

Owner

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

补充一点取舍视角：#7191 的 hex-escape 最小修复与 #7185 的 portable-pattern 重构方向不同——前者改动面小、和 #7151 的修法一致，适合快速止血；后者若把模式语义抽象成"可移植规范"，需要同时考虑 RE2/Rust 校验器的限制边界，周期更长但能根治同类问题。无论最终选哪个，建议把 advertisedPatternsVMode.test.ts 的覆盖从 compact profile 扩展到 full profile（本次两个坏模式都只在 full profile 暴露），避免再出现"默认 profile 测试通过、full profile 悄悄带病"的空白。

@XinwangTao commented on GitHub (Oct 26, 2026): 补充一点取舍视角：#7191 的 hex-escape 最小修复与 #7185 的 portable-pattern 重构方向不同——前者改动面小、和 #7151 的修法一致，适合快速止血；后者若把模式语义抽象成"可移植规范"，需要同时考虑 RE2/Rust 校验器的限制边界，周期更长但能根治同类问题。无论最终选哪个，建议把 advertisedPatternsVMode.test.ts 的覆盖从 compact profile 扩展到 full profile（本次两个坏模式都只在 full profile 暴露），避免再出现"默认 profile 测试通过、full profile 悄悄带病"的空白。

bsakaguchi referenced this issue

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

[PR #4324] [MERGED] fix(apple): preserve 128-bit keyed archive integers #6171

bsakaguchi referenced this issue

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

[PR #4422] [CLOSED] fix(artifacts): preserve binary keyed archive integers above Int64.max #6233