[PR #5937] fix(enhanced): bound batch decompile input size #7109

Open
opened 2026-11-01 21:45:26 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/5937
Author: @dakjdakd
Created: 10/21/2026
Status: 🔄 Open

Base: main ← Head: fix/batch-decompile-input-budget


📝 Commits (1)

  • 729d648 fix(enhanced): bound batch decompile input size

📊 Changes

4 files changed (+106 additions, -0 deletions)

View changed files

➕ src/application/EnhancedTools.input.test.ts (+35 -0)
➕ src/contracts/enhancedInputs.test.ts (+37 -0)
📝 src/contracts/enhancedInputs.ts (+1 -0)
📝 tests/boundary/mcp/enhancedTools.callPathsAndBatches.test.ts (+33 -0)

📄 Description

Summary

Fixes #5930

Bound batch_decompile.addresses with the repository's existing MAX_ENHANCED_RECORDS contract limit. Oversized requests now fail during shared input validation before provider dispatch, consistently across CLI, MCP, and direct application entry points.

Problem and expected behavior

The batch_decompile schema validated each address as a string but did not constrain the array length. That allowed a request to contain an arbitrary number of addresses even though enhanced analysis already defines a common maximum record budget. Because the schema is shared by the application and adapters, the missing bound affected every entry point that accepts this operation.

The expected behavior is a typed validation error for an array larger than MAX_ENHANCED_RECORDS, with the advertised schema exposing the same maxItems constraint. The provider must not be called for an invalid request. Legal batches retain their existing behavior and output contract.

Change and scope

  • Added .max(MAX_ENHANCED_RECORDS) to the canonical batch_decompile.addresses schema.
  • Kept the limit in the shared contract so CLI, MCP, and direct dispatch cannot drift apart.
  • Added contract checks for the exact maximum, one item over the maximum, and the generated JSON Schema maxItems value.
  • Added application and MCP boundary coverage proving typed validation and zero provider calls for oversized input.

No scheduler, provider adapter, output schema, or concurrency policy was changed. This PR bounds request admission; it does not redefine the resource policy for legal batches.

Contract and boundary impact

  • Semantic owner and earliest changed stage: enhanced input contract validation.
  • Contribution scope: routine input-safety and resource-bound fix within an existing operation.
  • CLI and MCP/tool-catalog contract: invalid oversized requests are rejected consistently; the operation name and valid input shape are unchanged.
  • Provider, bridge, target-format, or platform compatibility: no change for legal requests.
  • Evidence, artifact, or reconstruction contract: no change.
  • Generated metadata: the shared schema conversion now advertises the corresponding maxItems constraint.

Expected effects:

  • 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.
  • Not sure yet.

Evidence and regression coverage

  • Added contract tests for the maximum accepted length and the first rejected length.
  • Added JSON Schema checks for the advertised maxItems constraint and Ajv dialect validity.
  • Added application tests for typed AnalysisInputError and zero provider calls.
  • Added MCP tests for invalid request and invalid input behavior, catalog metadata, and zero provider calls.

Validation performed

  • Source contract, application, and MCP regression suites — passed.
  • npm run check:fast — passed.

Compatibility, safety, and release

  • Breaking changes or migration steps: callers sending more than MAX_ENHANCED_RECORDS addresses must split the request into bounded batches.
  • Real provider or target interaction: not applicable; rejection happens before provider dispatch.
  • Package or release metadata impact: the generated operation schema correctly advertises the existing shared limit.
  • Security, privacy, process, or containment review: this is an input-size admission bound and does not add authority or target interaction.

Author readiness

Human owner: @dakjdakd

  • 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.
  • Material scope and authority questions are resolved for this routine contract fix.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning contracts and generated metadata were checked where applicable.
  • The final diff was checked for unrelated cleanup.

🔄 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/5937 **Author:** [@dakjdakd](https://github.com/dakjdakd) **Created:** 10/21/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/batch-decompile-input-budget` --- ### 📝 Commits (1) - [`729d648`](https://github.com/morluto/rea/commit/729d648b2a842ac8cd503d6b43412bea9cc482d5) fix(enhanced): bound batch decompile input size ### 📊 Changes **4 files changed** (+106 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `src/application/EnhancedTools.input.test.ts` (+35 -0) ➕ `src/contracts/enhancedInputs.test.ts` (+37 -0) 📝 `src/contracts/enhancedInputs.ts` (+1 -0) 📝 `tests/boundary/mcp/enhancedTools.callPathsAndBatches.test.ts` (+33 -0) </details> ### 📄 Description ## Summary Fixes #5930 Bound `batch_decompile.addresses` with the repository's existing `MAX_ENHANCED_RECORDS` contract limit. Oversized requests now fail during shared input validation before provider dispatch, consistently across CLI, MCP, and direct application entry points. ## Problem and expected behavior The `batch_decompile` schema validated each address as a string but did not constrain the array length. That allowed a request to contain an arbitrary number of addresses even though enhanced analysis already defines a common maximum record budget. Because the schema is shared by the application and adapters, the missing bound affected every entry point that accepts this operation. The expected behavior is a typed validation error for an array larger than `MAX_ENHANCED_RECORDS`, with the advertised schema exposing the same `maxItems` constraint. The provider must not be called for an invalid request. Legal batches retain their existing behavior and output contract. ## Change and scope - Added `.max(MAX_ENHANCED_RECORDS)` to the canonical `batch_decompile.addresses` schema. - Kept the limit in the shared contract so CLI, MCP, and direct dispatch cannot drift apart. - Added contract checks for the exact maximum, one item over the maximum, and the generated JSON Schema `maxItems` value. - Added application and MCP boundary coverage proving typed validation and zero provider calls for oversized input. No scheduler, provider adapter, output schema, or concurrency policy was changed. This PR bounds request admission; it does not redefine the resource policy for legal batches. ## Contract and boundary impact - Semantic owner and earliest changed stage: enhanced input contract validation. - Contribution scope: routine input-safety and resource-bound fix within an existing operation. - CLI and MCP/tool-catalog contract: invalid oversized requests are rejected consistently; the operation name and valid input shape are unchanged. - Provider, bridge, target-format, or platform compatibility: no change for legal requests. - Evidence, artifact, or reconstruction contract: no change. - Generated metadata: the shared schema conversion now advertises the corresponding `maxItems` constraint. Expected effects: - [x] 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. - [ ] Not sure yet. ## Evidence and regression coverage - Added contract tests for the maximum accepted length and the first rejected length. - Added JSON Schema checks for the advertised `maxItems` constraint and Ajv dialect validity. - Added application tests for typed `AnalysisInputError` and zero provider calls. - Added MCP tests for invalid request and invalid input behavior, catalog metadata, and zero provider calls. ## Validation performed - Source contract, application, and MCP regression suites — passed. - `npm run check:fast` — passed. ## Compatibility, safety, and release - Breaking changes or migration steps: callers sending more than `MAX_ENHANCED_RECORDS` addresses must split the request into bounded batches. - Real provider or target interaction: not applicable; rejection happens before provider dispatch. - Package or release metadata impact: the generated operation schema correctly advertises the existing shared limit. - Security, privacy, process, or containment review: this is an input-size admission bound and does not add authority or target interaction. ## Author readiness Human owner: @dakjdakd - [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. - [x] Material scope and authority questions are resolved for this routine contract fix. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning contracts and generated metadata were checked where applicable. - [x] The final diff was checked for unrelated cleanup. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
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#7109
No description provided.