[PR #6414] [MERGED] fix(evm): report the carrier input allowance as a file-size constraint #7343

Closed
opened 2026-11-01 21:47:12 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

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

Base: main ← Head: fix/evm-input-size-resource-constraint


📝 Commits (1)

  • d153fdc fix(evm): report the carrier input allowance as a file-size constraint

📊 Changes

3 files changed (+76 additions, -11 deletions)

View changed files

📝 docs/evm-bytecode.md (+3 -1)
📝 src/evm/EvmoleFailures.test.ts (+55 -0)
📝 src/evm/EvmoleFailures.ts (+18 -10)

📄 Description

Summary

inspect_evm_interface reported a carrier over the fixed 4 MiB input allowance as invalid_request / invalid_input with an out_of_range issue against path and input-schema recovery, instead of a typed resource refusal. This keeps the refusal, the limit, and non-retryability, but classifies it as resource_constraint with resource: "file-size" and reported_limits.maximum_input_bytes, following the WABT input translator.

Fixes #6053

Problem and expected behavior

Selecting a 4,194,305-byte raw carrier with inspect({path, encoding: "raw"}) was projected as a non-retryable invalid_request whose only record of the 4 MiB allowance was issue message text, with recovery directing callers to the input schema or CLI usage. Schema or usage discovery cannot raise a measured input byte allowance. The stable reader already reports this refusal as ArtifactReaderFailure("limit", ..., {boundary: "file-size"}); the EVM failure translator grouped that limit reason with path and format reader refusals under AnalysisInputError.

Expected: keep refusing oversized inputs; return resource_constraint / resource_constraint with resource: "file-size", reported_limits.maximum_input_bytes: 4194304, retryable: false, and recovery explaining the fixed input allowance. Distinct input errors for malformed paths or carrier representations are retained.

Change and scope

src/evm/EvmoleFailures.ts now maps an artifact-read-phase ArtifactReaderFailure with reason limit and boundary file-size to a non-retryable AnalysisResourceConstraintError with maximum_input_bytes and input-specific recovery (mirrors src/wasm/WabtFailures.ts for the identical reader refusal). path and format reader refusals keep their existing AnalysisInputError projection. The reply-read path is untouched: it converts its own failures to AnalysisOutputError locally, and the worker-phase SIGXFSZ/EFBIG branch keeps its separate file-size diagnostic. One sentence in docs/evm-bytecode.md documents the new classification, mirroring docs/wasm-artifacts.md.

Not included: no limit change, no new tool or schema field, no target execution, and no change to worker or reply allowances (#5848 covers the reply allowance separately).

Follow the contribution scope.
Unresolved scope, authority, side effects, or required verification block
integration. Link the required maintainer scope decision for new providers or
capabilities involving target execution, injection, mutation, or protection
recovery; ordinary fixes within existing boundaries may state "not applicable".
Draft PRs may leave the scope decision pending and the readiness and merge checklists
unchecked. Maintainers can help resolve open questions.

Scope decision: not applicable (error classification fix within an existing operation; no new capability, authority, or limit).

Contract and boundary impact

  • Semantic owner and earliest changed stage: EVM interface failure translation (src/evm/EvmoleFailures.ts), earliest stage artifact-read admission.
  • Contribution scope fit and linked maintainer decision: ordinary fix within existing boundaries; not applicable.
  • CLI and MCP/tool-catalog contract: error code/category/retryable/recovery for the oversized-carrier refusal change from invalid_request/invalid_input/schema recovery to resource_constraint/resource_constraint/fixed-allowance recovery; details gains resource and reported_limits.maximum_input_bytes and loses the issues entry. No tool schemas or catalog metadata change.
  • Provider, bridge, target-format, or platform compatibility: none; classification-only, provider behavior unchanged.
  • Evidence, artifact, provenance, or reconstruction contract: none.
  • Target selection, authority, upstream behavior, and cleanup details: not applicable; refusal happens before worker runtime creation, cleanup observations are preserved through existing cleanupOptions.
  • Generated metadata (docs/public/product-catalog.json), package, or installation impact: none; no tool schemas changed.

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. (pre-existing carrier read whose refusal classification changed; no new reading)
  • 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.

Evidence and regression coverage

  • Tests added or updated: src/evm/EvmoleFailures.test.ts gains a projection test asserting resource_constraint / resource_constraint / retryable: false / details.reported_limits.maximum_input_bytes: 4194304, the allowance-bearing message, and the non-truncation recovery, plus parametrized cases keeping path/format reader refusals as invalid_request with invalid_format issues.
  • Base reproduction: on the unmodified base revision (source change stashed, tests kept) the new resource-constraint test fails (1 failed / 13) with the projection still invalid_request, matching the issue's executed CLI/MCP output; with the fix the file passes 13/13.
  • User-visible CLI/MCP output: not separately executed; the tested projection is the canonical projection the CLI and MCP handlers deliver (src/cli/evmCommands.ts and src/server/registerEvmTools.ts call the same service by source inspection, as recorded in the issue).
  • Remaining proof gaps: real Linux admission and a real 4 MiB+ carrier through the CLI/MCP transport were not run locally (EVM worker admission is Linux-only; the Windows source checkout cannot run that lane). CI Linux lanes own the deterministic suite.

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

  • npm run test:focused -- src/evm/EvmoleFailures.test.ts — 13 passed; on the unfixed base the new regression fails (1 failed), confirming it catches the reported defect.
  • node node_modules/vitest/vitest.mjs run tests/boundary/mcp/evmInterfaceMcp.test.ts --maxWorkers=1 — 11 passed.
  • node node_modules/vitest/vitest.mjs run tests/boundary/evm/evmoleInterfaceProvider.test.ts --maxWorkers=1 — 2 passed, 30 skipped (Linux-only provider cases skip on Windows, as documented for Windows source checkouts).
  • node node_modules/vitest/vitest.mjs run src/application/evm/EvmInterfaceService.test.ts tests/composition/evmModuleContract.test.ts --maxWorkers=1 — 18 passed.
  • npm run verify:module-boundaries — passed, 2735 source files checked.
  • npm run verify:test-discovery — passed, 2090 test files discovered exactly once.
  • npx oxlint src/evm/EvmoleFailures.ts src/evm/EvmoleFailures.test.ts — 0 errors, 3 warnings identical to the unmodified baseline.
  • npx oxfmt --check (changed files) — all matched files use the correct format.
  • npm run check:fast — not completed locally: the pinned TypeScript 7 native compiler stalls on this Windows host (near-zero progress over 30+ minutes); recorded as a validation gap, CI owns the deterministic suite.
  • Real-provider/real-Linux EVM coverage — unavailable on this Windows host; not run.

Compatibility, safety, and release

  • Breaking changes or migration steps: none intended. Callers branching on the old invalid_request code for oversized carriers will see resource_constraint; the refusal, its limit, and non-retryability are unchanged, and release-please records this as a fix.
  • Real Hopper/Ghidra, browser, or OS coverage: none; classification-only change with translator-level regression coverage.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: none; no new target interaction, execution, or authority.

Author readiness

Human owner: @Bilalmesk

  • 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/6414 **Author:** [@Bilalmesk](https://github.com/Bilalmesk) **Created:** 10/22/2026 **Status:** ✅ Merged **Merged:** 10/23/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/evm-input-size-resource-constraint` --- ### 📝 Commits (1) - [`d153fdc`](https://github.com/morluto/rea/commit/d153fdcc67a69e7e7b528bd75fdf9d1563472421) fix(evm): report the carrier input allowance as a file-size constraint ### 📊 Changes **3 files changed** (+76 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `docs/evm-bytecode.md` (+3 -1) 📝 `src/evm/EvmoleFailures.test.ts` (+55 -0) 📝 `src/evm/EvmoleFailures.ts` (+18 -10) </details> ### 📄 Description ## Summary `inspect_evm_interface` reported a carrier over the fixed 4 MiB input allowance as `invalid_request` / `invalid_input` with an `out_of_range` issue against `path` and input-schema recovery, instead of a typed resource refusal. This keeps the refusal, the limit, and non-retryability, but classifies it as `resource_constraint` with `resource: "file-size"` and `reported_limits.maximum_input_bytes`, following the WABT input translator. Fixes #6053 ## Problem and expected behavior Selecting a 4,194,305-byte raw carrier with `inspect({path, encoding: "raw"})` was projected as a non-retryable `invalid_request` whose only record of the 4 MiB allowance was issue message text, with recovery directing callers to the input schema or CLI usage. Schema or usage discovery cannot raise a measured input byte allowance. The stable reader already reports this refusal as `ArtifactReaderFailure("limit", ..., {boundary: "file-size"})`; the EVM failure translator grouped that `limit` reason with `path` and `format` reader refusals under `AnalysisInputError`. Expected: keep refusing oversized inputs; return `resource_constraint` / `resource_constraint` with `resource: "file-size"`, `reported_limits.maximum_input_bytes: 4194304`, `retryable: false`, and recovery explaining the fixed input allowance. Distinct input errors for malformed paths or carrier representations are retained. ## Change and scope `src/evm/EvmoleFailures.ts` now maps an `artifact-read`-phase `ArtifactReaderFailure` with reason `limit` and boundary `file-size` to a non-retryable `AnalysisResourceConstraintError` with `maximum_input_bytes` and input-specific recovery (mirrors `src/wasm/WabtFailures.ts` for the identical reader refusal). `path` and `format` reader refusals keep their existing `AnalysisInputError` projection. The reply-read path is untouched: it converts its own failures to `AnalysisOutputError` locally, and the worker-phase SIGXFSZ/EFBIG branch keeps its separate file-size diagnostic. One sentence in `docs/evm-bytecode.md` documents the new classification, mirroring `docs/wasm-artifacts.md`. Not included: no limit change, no new tool or schema field, no target execution, and no change to worker or reply allowances (#5848 covers the reply allowance separately). Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). Unresolved scope, authority, side effects, or required verification block integration. Link the required maintainer scope decision for new providers or capabilities involving target execution, injection, mutation, or protection recovery; ordinary fixes within existing boundaries may state "not applicable". Draft PRs may leave the scope decision pending and the readiness and merge checklists unchecked. Maintainers can help resolve open questions. Scope decision: not applicable (error classification fix within an existing operation; no new capability, authority, or limit). ## Contract and boundary impact - Semantic owner and earliest changed stage: EVM interface failure translation (`src/evm/EvmoleFailures.ts`), earliest stage artifact-read admission. - Contribution scope fit and linked maintainer decision: ordinary fix within existing boundaries; not applicable. - CLI and MCP/tool-catalog contract: error code/category/retryable/recovery for the oversized-carrier refusal change from `invalid_request`/`invalid_input`/schema recovery to `resource_constraint`/`resource_constraint`/fixed-allowance recovery; `details` gains `resource` and `reported_limits.maximum_input_bytes` and loses the `issues` entry. No tool schemas or catalog metadata change. - Provider, bridge, target-format, or platform compatibility: none; classification-only, provider behavior unchanged. - Evidence, artifact, provenance, or reconstruction contract: none. - Target selection, authority, upstream behavior, and cleanup details: not applicable; refusal happens before worker runtime creation, cleanup observations are preserved through existing `cleanupOptions`. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none; no tool schemas changed. Expected effects (check known effects; use documentation-only on its own). Unchecked items do not establish absence; leave uncertainties visible. - [x] Read existing files or captured data. (pre-existing carrier read whose refusal classification changed; no new reading) - [ ] 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. ## Evidence and regression coverage - Tests added or updated: `src/evm/EvmoleFailures.test.ts` gains a projection test asserting `resource_constraint` / `resource_constraint` / `retryable: false` / `details.reported_limits.maximum_input_bytes: 4194304`, the allowance-bearing message, and the non-truncation recovery, plus parametrized cases keeping `path`/`format` reader refusals as `invalid_request` with `invalid_format` issues. - Base reproduction: on the unmodified base revision (source change stashed, tests kept) the new resource-constraint test fails (1 failed / 13) with the projection still `invalid_request`, matching the issue's executed CLI/MCP output; with the fix the file passes 13/13. - User-visible CLI/MCP output: not separately executed; the tested projection is the canonical projection the CLI and MCP handlers deliver (`src/cli/evmCommands.ts` and `src/server/registerEvmTools.ts` call the same service by source inspection, as recorded in the issue). - Remaining proof gaps: real Linux admission and a real 4 MiB+ carrier through the CLI/MCP transport were not run locally (EVM worker admission is Linux-only; the Windows source checkout cannot run that lane). CI Linux lanes own the deterministic suite. 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 - `npm run test:focused -- src/evm/EvmoleFailures.test.ts` — 13 passed; on the unfixed base the new regression fails (1 failed), confirming it catches the reported defect. - `node node_modules/vitest/vitest.mjs run tests/boundary/mcp/evmInterfaceMcp.test.ts --maxWorkers=1` — 11 passed. - `node node_modules/vitest/vitest.mjs run tests/boundary/evm/evmoleInterfaceProvider.test.ts --maxWorkers=1` — 2 passed, 30 skipped (Linux-only provider cases skip on Windows, as documented for Windows source checkouts). - `node node_modules/vitest/vitest.mjs run src/application/evm/EvmInterfaceService.test.ts tests/composition/evmModuleContract.test.ts --maxWorkers=1` — 18 passed. - `npm run verify:module-boundaries` — passed, 2735 source files checked. - `npm run verify:test-discovery` — passed, 2090 test files discovered exactly once. - `npx oxlint src/evm/EvmoleFailures.ts src/evm/EvmoleFailures.test.ts` — 0 errors, 3 warnings identical to the unmodified baseline. - `npx oxfmt --check` (changed files) — all matched files use the correct format. - `npm run check:fast` — not completed locally: the pinned TypeScript 7 native compiler stalls on this Windows host (near-zero progress over 30+ minutes); recorded as a validation gap, CI owns the deterministic suite. - Real-provider/real-Linux EVM coverage — unavailable on this Windows host; not run. ## Compatibility, safety, and release - Breaking changes or migration steps: none intended. Callers branching on the old `invalid_request` code for oversized carriers will see `resource_constraint`; the refusal, its limit, and non-retryability are unchanged, and release-please records this as a fix. - Real Hopper/Ghidra, browser, or OS coverage: none; classification-only change with translator-level regression coverage. - Package or release metadata impact: none. - Security, privacy, process, or containment review: none; no new target interaction, execution, or authority. ## Author readiness Human owner: @Bilalmesk - [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 - [ ] 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. - [ ] 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:47:12 +00:00
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#7343
No description provided.