[PR #5239] [CLOSED] fix(evm): clarify worker address space as profile ceiling in limitations #6831

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

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/5239
Author: @Sarthak-Pandey
Created: 10/19/2026
Status: ❌ Closed

Base: main ← Head: fix/evm-address-space-limit-wording


📝 Commits (1)

  • ca3f893 fix(evm): clarify worker address space as profile ceiling in limitations

📊 Changes

3 files changed (+6 additions, -3 deletions)

View changed files

📝 docs/evm-bytecode.md (+2 -2)
📝 src/evm/EvmoleInterfaceProvider.ts (+1 -1)
📝 tests/boundary/evm/evmoleInterfaceProvider.test.ts (+3 -0)

📄 Description

Summary

Fixes #5087.

Clarifies the EVM worker's virtual address-space limitation description as an "up to 3 GiB virtual address-space profile ceiling" instead of an unconditional fixed 3 GiB limit. This prevents contradictory evidence when a tighter inherited soft limit (e.g. 2 GiB) is selected and reported in address_space_bytes.

Problem and expected behavior

On Linux x64 hosts where an inherited soft address-space limit below 3 GiB is present (e.g., 2 GiB / 2147483648 bytes), selectEvmWorkerLimits correctly selects and configures 2147483648 bytes.

However, in the returned limitations array:

  • limitations[0] reports: Configured worker resource soft limits: address_space_bytes=2147483648...
  • limitations[6] claimed: The owned worker has a 256 MiB JavaScript heap, 3 GiB virtual address-space limit and 30-second deadline...

This resulted in contradictory statements within the same evidence report. The expected behavior is to describe 3 GiB as the maximum profile ceiling so that tighter inherited limits do not contradict the worker's operational profile sentence.

Change and scope

  • Updated src/evm/EvmoleInterfaceProvider.ts line 414 to describe up to 3 GiB virtual address-space profile ceiling.
  • Updated docs/evm-bytecode.md line 108 to align documentation with the profile ceiling wording.
  • Added assertion in tests/boundary/evm/evmoleInterfaceProvider.test.ts verifying the updated limitation entry on successful inspection.

Follow the contribution scope: Ordinary wording fix within existing boundaries; maintainer scope decision is not applicable.

Contract and boundary impact

  • Semantic owner and earliest changed stage: EvmoleInterfaceProvider, result construction / limitations projection.
  • Contribution scope fit and linked maintainer decision: Not applicable (bug fix within existing provider boundary).
  • CLI and MCP/tool-catalog contract: Unchanged schema; improved semantic accuracy of inline evidence limitations.
  • Provider, bridge, target-format, or platform compatibility: Linux x64 EVM provider.
  • Evidence, artifact, provenance, or reconstruction contract: Preserved; resolves internal contradiction between configured limit entry and worker envelope sentence.
  • Target selection, authority, upstream behavior, and cleanup details (if applicable): None.
  • Generated metadata impact: None.

Expected effects:

  • Documentation or usability only; no target interaction.

Evidence and regression coverage

  • Tests added or updated: tests/boundary/evm/evmoleInterfaceProvider.test.ts (asserts the updated limitation string on success).
  • Base reproduction or other evidence: Source analysis of #5087 demonstrating the contradiction between limitations[0] interpolation and limitations[6] hardcoded text.
  • User-visible CLI/MCP output: Limitations array contains "The owned worker has a 256 MiB JavaScript heap, up to 3 GiB virtual address-space profile ceiling and 30-second deadline. Virtual address space is distinct from resident memory; limits fail without partial success.".
  • Remaining proof gaps: Production provider execution requires a Linux x64 host with prlimit; static tracing and boundary test structure verified on development host.

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

  • git diff --cached — verified exact 3-file diff in provider, documentation, and boundary test.
  • Static verification of EvmoleInterfaceProvider.ts, EvmWorkerLimits.ts, and EvmoleRelease.ts.

Compatibility, safety, and release

  • Breaking changes or migration steps: None.
  • Real Hopper/Ghidra, browser, or OS coverage: Requires Linux x64 for real provider runtime.
  • Package or release metadata impact: None.
  • Security, privacy, process, or containment review: Wording-only change; prlimit enforcement logic and process isolation are unchanged.

Author readiness

Human owner: @Sarthak-Pandey

  • 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/5239 **Author:** [@Sarthak-Pandey](https://github.com/Sarthak-Pandey) **Created:** 10/19/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/evm-address-space-limit-wording` --- ### 📝 Commits (1) - [`ca3f893`](https://github.com/morluto/rea/commit/ca3f893d002a0fca2bb4e1a039b120373182276a) fix(evm): clarify worker address space as profile ceiling in limitations ### 📊 Changes **3 files changed** (+6 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `docs/evm-bytecode.md` (+2 -2) 📝 `src/evm/EvmoleInterfaceProvider.ts` (+1 -1) 📝 `tests/boundary/evm/evmoleInterfaceProvider.test.ts` (+3 -0) </details> ### 📄 Description ## Summary Fixes #5087. Clarifies the EVM worker's virtual address-space limitation description as an "up to 3 GiB virtual address-space profile ceiling" instead of an unconditional fixed 3 GiB limit. This prevents contradictory evidence when a tighter inherited soft limit (e.g. 2 GiB) is selected and reported in `address_space_bytes`. ## Problem and expected behavior On Linux x64 hosts where an inherited soft address-space limit below 3 GiB is present (e.g., 2 GiB / `2147483648` bytes), `selectEvmWorkerLimits` correctly selects and configures `2147483648` bytes. However, in the returned `limitations` array: - `limitations[0]` reports: `Configured worker resource soft limits: address_space_bytes=2147483648...` - `limitations[6]` claimed: `The owned worker has a 256 MiB JavaScript heap, 3 GiB virtual address-space limit and 30-second deadline...` This resulted in contradictory statements within the same evidence report. The expected behavior is to describe 3 GiB as the maximum profile ceiling so that tighter inherited limits do not contradict the worker's operational profile sentence. ## Change and scope - Updated `src/evm/EvmoleInterfaceProvider.ts` line 414 to describe `up to 3 GiB virtual address-space profile ceiling`. - Updated `docs/evm-bytecode.md` line 108 to align documentation with the profile ceiling wording. - Added assertion in `tests/boundary/evm/evmoleInterfaceProvider.test.ts` verifying the updated limitation entry on successful inspection. Follow the contribution scope: Ordinary wording fix within existing boundaries; maintainer scope decision is not applicable. ## Contract and boundary impact - Semantic owner and earliest changed stage: `EvmoleInterfaceProvider`, result construction / limitations projection. - Contribution scope fit and linked maintainer decision: Not applicable (bug fix within existing provider boundary). - CLI and MCP/tool-catalog contract: Unchanged schema; improved semantic accuracy of inline evidence limitations. - Provider, bridge, target-format, or platform compatibility: Linux x64 EVM provider. - Evidence, artifact, provenance, or reconstruction contract: Preserved; resolves internal contradiction between configured limit entry and worker envelope sentence. - Target selection, authority, upstream behavior, and cleanup details (if applicable): None. - Generated metadata impact: None. Expected effects: - [x] Documentation or usability only; no target interaction. ## Evidence and regression coverage - Tests added or updated: `tests/boundary/evm/evmoleInterfaceProvider.test.ts` (asserts the updated limitation string on success). - Base reproduction or other evidence: Source analysis of #5087 demonstrating the contradiction between `limitations[0]` interpolation and `limitations[6]` hardcoded text. - User-visible CLI/MCP output: Limitations array contains `"The owned worker has a 256 MiB JavaScript heap, up to 3 GiB virtual address-space profile ceiling and 30-second deadline. Virtual address space is distinct from resident memory; limits fail without partial success."`. - Remaining proof gaps: Production provider execution requires a Linux x64 host with `prlimit`; static tracing and boundary test structure verified on development host. 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 - `git diff --cached` — verified exact 3-file diff in provider, documentation, and boundary test. - Static verification of `EvmoleInterfaceProvider.ts`, `EvmWorkerLimits.ts`, and `EvmoleRelease.ts`. ## Compatibility, safety, and release - Breaking changes or migration steps: None. - Real Hopper/Ghidra, browser, or OS coverage: Requires Linux x64 for real provider runtime. - Package or release metadata impact: None. - Security, privacy, process, or containment review: Wording-only change; `prlimit` enforcement logic and process isolation are unchanged. ## Author readiness Human owner: @Sarthak-Pandey - [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:43:21 +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#6831
No description provided.