morluto/rea

Fork 0

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

[PR #6270] [MERGED] fix(process): name the pattern field in default invalid-regex errors #7244

New issue

Closed

opened 2026-11-01 21:46:26 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:46:26 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6270
Author: @Abelo9996
Created: 10/22/2026
Status: ✅ Merged
Merged: 10/22/2026
Merged by: @morluto

Base: main ← Head: fix-6107-kuna-regex-pattern-issue

📝 Commits (1)

70ee442 fix(process): name the pattern field in default invalid-regex errors

📊 Changes

3 files changed (+49 additions, -4 deletions)

View changed files

📝 src/process/RegexMatcher.ts (+13 -3)
📝 tests/boundary/process/regexMatcher.test.ts (+29 -0)
📝 tests/boundary/providers/kuna/kunaStrings.test.ts (+7 -1)

📄 Description

Summary

Fixes #6107.

Kuna search_strings and search_procedures with an invalid regex (pattern: "[", mode: "regex") were correctly refused as invalid_request / invalid_input with input-contract recovery, but without details.issues, so the "Correct the listed fields" remediation listed nothing. The shared regex matcher's default invalid-pattern error now carries {"path":["pattern"],"reason":"invalid_format","message":"Supply a valid regular expression."}, the same issue IDA already returns for the same input.

Problem and expected behavior

Both Kuna searches delegate to matchRegexValues in src/process/RegexMatcher.ts without an invalidPattern callback. The default branch built AnalysisInputError with only a userMessage, so issues defaulted to [] and the projector emitted no details:

{"code":"invalid_request","category":"invalid_input","message":"Invalid regex pattern: Invalid regular expression: /[/iu: Unterminated character class","retryable":false,"remediation":{"action":"Read the declared input schema or CLI usage for search_strings; if using MCP and the catalog may be stale, call tools/list. Correct the listed fields, then retry. Do not repeat the unchanged call."},"recovery":{"kind":"inspect_input_contract","operation":"search_strings"}}

Expected: keep the rejection, message, operation and recovery, and add a structured pattern issue with invalid_format.

Change and scope

Pass the pattern issue to the default AnalysisInputError in matchRegexValues, with the same path, reason and message as src/ida/IdaInput.ts. The matcher owns the rejected argument, so fixing the default there covers both Kuna search operations in one place.

The only other caller, Hopper, passes its own invalidPattern and is unchanged (its HopperRemoteError handling is tracked separately in #5986). The existing Hopper invalid-pattern test still passes.

Follow the contribution scope.
Scope decision: not applicable (ordinary fix within existing boundaries).

Contract and boundary impact

Semantic owner and earliest changed stage: matchRegexValues default invalid-pattern error (shared regex worker reply handling).
Contribution scope fit and linked maintainer decision: ordinary bug fix, not applicable.
CLI and MCP/tool-catalog contract: no schema change. Kuna invalid-regex refusals now project details.issues naming pattern.
Provider, bridge, target-format, or platform compatibility: affects callers without an invalidPattern override, which today is Kuna only. Hopper keeps its override.
Evidence, artifact, provenance, or reconstruction contract: none.
Target selection, authority, upstream behavior, and cleanup details (if applicable): unchanged. Worker lifetime, deadline and heap handling are untouched.
Generated metadata (docs/public/product-catalog.json), package, or installation impact (CI generates and validates ignored catalogs and skills/; edit authored instructions in .agents/skills/reverse-engineer-anything/ and never commit build outputs): none.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

(Diagnostic metadata only; the invalid pattern is rejected by the existing worker before any match.)

Evidence and regression coverage

Tests added or updated:
- tests/boundary/process/regexMatcher.test.ts: new test that a default invalid-pattern refusal from matchRegexValues projects invalid_request / invalid_input, inspect_input_contract recovery and the pattern issue.
- tests/boundary/providers/kuna/kunaStrings.test.ts: the existing Kuna search_strings invalid-regex assertion now also checks issues: [{ path: ["pattern"], reason: "invalid_format" }].

Base reproduction (executed): with the test changes and without the fix:

× shares a typed string scan across concurrent searches and exact address reads without analysis
× names the rejected pattern field for a default invalid-pattern refusal
-     "issues": [
+     "issues": [],
      Tests  2 failed | 29 passed (31)

With the fix, both pass.

User-visible CLI/MCP output (if applicable): projectAnalysisError on the simulated Kuna session for pattern: "[". Before, as shown above for both operations. After, for search_procedures (search_strings is identical apart from the operation):

{"code":"invalid_request","category":"invalid_input","message":"Invalid regex pattern: Invalid regular expression: /[/iu: Unterminated character class","retryable":false,"remediation":{"action":"Read the declared input schema or CLI usage for search_procedures; if using MCP and the catalog may be stale, call tools/list. Correct the listed fields, then retry. Do not repeat the unchanged call."},"recovery":{"kind":"inspect_input_contract","operation":"search_procedures"},"details":{"operation":"search_procedures","issues":[{"path":["pattern"],"reason":"invalid_format","message":"Supply a valid regular expression."}]}}

Remaining proof gaps: no real Kuna engine. MCP transport and CLI delivery were not separately run; the output above is the shared projector both use. The issue does not include the regex error offset, which the existing message already carries.

For evidence-bearing changes:

Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

Run with the pinned Node 24.18.0 on macOS arm64.

npm run test:focused -- tests/boundary/process/regexMatcher.test.ts tests/boundary/providers/kuna/kunaStrings.test.ts src/process/RegexMatcher.test.ts: 3 files, 78 tests passed (2 failures without the fix, shown above)
npm run test:focused -- tests/boundary/providers/hopper/hopperRegexFailure.test.ts tests/boundary/providers/kuna/kunaProvider.test.ts tests/boundary/mcp/nativeInventoryViewsMcp.test.ts tests/boundary/mcp/ghidraInventoryMcp.test.ts src/hopper/HopperRegexSearch.test.ts: 5 files, 64 tests passed
npm run check tasks: typecheck, lint:built (0 errors), knip, metadata:check and verify:architecture-guards passed. format:check was run as oxfmt --check on the three changed files (clean), because the repo-wide run in my checkout also picked up unrelated untracked local notes.

Compatibility, safety, and release

Breaking changes or migration steps: none. details is optional and is now present for this refusal.
Real Hopper/Ghidra, browser, or OS coverage: macOS only, simulated Kuna executable. Hopper behavior covered by its existing tests only.
Package or release metadata impact: none.
Security, privacy, process, or containment review: the issue names the field with a fixed message; the pattern itself is not added to details.

Author readiness

Human owner: @Abelo9996

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/6270 **Author:** [@Abelo9996](https://github.com/Abelo9996) **Created:** 10/22/2026 **Status:** ✅ Merged **Merged:** 10/22/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix-6107-kuna-regex-pattern-issue` --- ### 📝 Commits (1) - [`70ee442`](https://github.com/morluto/rea/commit/70ee44242d1475f7fda734752d5b3a8628e2dcab) fix(process): name the pattern field in default invalid-regex errors ### 📊 Changes **3 files changed** (+49 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `src/process/RegexMatcher.ts` (+13 -3) 📝 `tests/boundary/process/regexMatcher.test.ts` (+29 -0) 📝 `tests/boundary/providers/kuna/kunaStrings.test.ts` (+7 -1) </details> ### 📄 Description ## Summary Fixes #6107. Kuna `search_strings` and `search_procedures` with an invalid regex (`pattern: "["`, `mode: "regex"`) were correctly refused as `invalid_request` / `invalid_input` with input-contract recovery, but without `details.issues`, so the "Correct the listed fields" remediation listed nothing. The shared regex matcher's default invalid-pattern error now carries `{"path":["pattern"],"reason":"invalid_format","message":"Supply a valid regular expression."}`, the same issue IDA already returns for the same input. ## Problem and expected behavior Both Kuna searches delegate to `matchRegexValues` in `src/process/RegexMatcher.ts` without an `invalidPattern` callback. The default branch built `AnalysisInputError` with only a `userMessage`, so issues defaulted to `[]` and the projector emitted no `details`: ```json {"code":"invalid_request","category":"invalid_input","message":"Invalid regex pattern: Invalid regular expression: /[/iu: Unterminated character class","retryable":false,"remediation":{"action":"Read the declared input schema or CLI usage for search_strings; if using MCP and the catalog may be stale, call tools/list. Correct the listed fields, then retry. Do not repeat the unchanged call."},"recovery":{"kind":"inspect_input_contract","operation":"search_strings"}} ``` Expected: keep the rejection, message, operation and recovery, and add a structured `pattern` issue with `invalid_format`. ## Change and scope Pass the `pattern` issue to the default `AnalysisInputError` in `matchRegexValues`, with the same path, reason and message as `src/ida/IdaInput.ts`. The matcher owns the rejected argument, so fixing the default there covers both Kuna search operations in one place. The only other caller, Hopper, passes its own `invalidPattern` and is unchanged (its `HopperRemoteError` handling is tracked separately in #5986). The existing Hopper invalid-pattern test still passes. Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). Scope decision: not applicable (ordinary fix within existing boundaries). ## Contract and boundary impact - Semantic owner and earliest changed stage: `matchRegexValues` default invalid-pattern error (shared regex worker reply handling). - Contribution scope fit and linked maintainer decision: ordinary bug fix, not applicable. - CLI and MCP/tool-catalog contract: no schema change. Kuna invalid-regex refusals now project `details.issues` naming `pattern`. - Provider, bridge, target-format, or platform compatibility: affects callers without an `invalidPattern` override, which today is Kuna only. Hopper keeps its override. - Evidence, artifact, provenance, or reconstruction contract: none. - Target selection, authority, upstream behavior, and cleanup details (if applicable): unchanged. Worker lifetime, deadline and heap handling are untouched. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact (CI generates and validates ignored catalogs and `skills/`; edit authored instructions in `.agents/skills/reverse-engineer-anything/` and never commit build outputs): none. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [ ] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [x] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. (Diagnostic metadata only; the invalid pattern is rejected by the existing worker before any match.) ## Evidence and regression coverage - Tests added or updated: - `tests/boundary/process/regexMatcher.test.ts`: new test that a default invalid-pattern refusal from `matchRegexValues` projects `invalid_request` / `invalid_input`, `inspect_input_contract` recovery and the `pattern` issue. - `tests/boundary/providers/kuna/kunaStrings.test.ts`: the existing Kuna `search_strings` invalid-regex assertion now also checks `issues: [{ path: ["pattern"], reason: "invalid_format" }]`. - Base reproduction (executed): with the test changes and without the fix: ``` × shares a typed string scan across concurrent searches and exact address reads without analysis × names the rejected pattern field for a default invalid-pattern refusal - "issues": [ + "issues": [], Tests 2 failed | 29 passed (31) ``` With the fix, both pass. - User-visible CLI/MCP output (if applicable): `projectAnalysisError` on the simulated Kuna session for `pattern: "["`. Before, as shown above for both operations. After, for `search_procedures` (`search_strings` is identical apart from the operation): ```json {"code":"invalid_request","category":"invalid_input","message":"Invalid regex pattern: Invalid regular expression: /[/iu: Unterminated character class","retryable":false,"remediation":{"action":"Read the declared input schema or CLI usage for search_procedures; if using MCP and the catalog may be stale, call tools/list. Correct the listed fields, then retry. Do not repeat the unchanged call."},"recovery":{"kind":"inspect_input_contract","operation":"search_procedures"},"details":{"operation":"search_procedures","issues":[{"path":["pattern"],"reason":"invalid_format","message":"Supply a valid regular expression."}]}} ``` - Remaining proof gaps: no real Kuna engine. MCP transport and CLI delivery were not separately run; the output above is the shared projector both use. The issue does not include the regex error offset, which the existing message already carries. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed Run with the pinned Node 24.18.0 on macOS arm64. - `npm run test:focused -- tests/boundary/process/regexMatcher.test.ts tests/boundary/providers/kuna/kunaStrings.test.ts src/process/RegexMatcher.test.ts`: 3 files, 78 tests passed (2 failures without the fix, shown above) - `npm run test:focused -- tests/boundary/providers/hopper/hopperRegexFailure.test.ts tests/boundary/providers/kuna/kunaProvider.test.ts tests/boundary/mcp/nativeInventoryViewsMcp.test.ts tests/boundary/mcp/ghidraInventoryMcp.test.ts src/hopper/HopperRegexSearch.test.ts`: 5 files, 64 tests passed - `npm run check` tasks: `typecheck`, `lint:built` (0 errors), `knip`, `metadata:check` and `verify:architecture-guards` passed. `format:check` was run as `oxfmt --check` on the three changed files (clean), because the repo-wide run in my checkout also picked up unrelated untracked local notes. ## Compatibility, safety, and release - Breaking changes or migration steps: none. `details` is optional and is now present for this refusal. - Real Hopper/Ghidra, browser, or OS coverage: macOS only, simulated Kuna executable. Hopper behavior covered by its existing tests only. - Package or release metadata impact: none. - Security, privacy, process, or containment review: the issue names the field with a fixed message; the pattern itself is not added to `details`. ## Author readiness Human owner: @Abelo9996 - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-11-01 21:46:26 +00:00