morluto/rea

Fork 0

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

[GH-ISSUE #8421] [Bug] Address context gives misleading recovery when Evidence capacity is exhausted #6596

New issue

Open

opened 2026-11-01 21:12:32 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-11-01 21:12:32 +00:00

Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8421

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 a real Ghidra observation and an artificially limited investigation Evidence allowance, inspect_address_context preserves a successful name facet but reports a failed procedure facet as unavailable and advises calling resolve_containing_procedure directly. That direct call returns resource_constraint with the actual retention limit and recovery action. Repeating the call did not recover the observation in this control.

Reproduction

Construct the production BinarySession and Ghidra provider with InvestigationRecords({maximumRepresentationBytes: 20000}); connect the real REA MCP server using the SDK's in-memory transport. This is a controlled injected allowance, not a public CLI setting.
Open an owned arm64 Mach-O with real Ghidra 12.1.4 and inspect a valid function address, with the actual selected document identity.
The context response returned name: {state: "available", value: "entry"} and an unavailable procedure facet advising a direct procedure call. One name Evidence record occupied 15,080 representation bytes of the 20,000-byte allowance.
Call resolve_containing_procedure with the same address and document. The response reported resource_constraint for record_evidence, including the occupied allowance and instructions to export and start a new investigation or increase heap before starting it.

A default-allowance control on the same target produced an available procedure facet and a successful direct name observation. A separate zero-allowance control produced unavailable name and procedure facets. These are single runs, not an exhaustion test of the production default heap. The target was not executed and its SHA-256 was unchanged.

Expected behavior

Preserve the successful facet and convey the actual capacity refusal and its actionable recovery on the failed facet, or otherwise provide an explicitly designed partial-result recovery. Do not classify a retention refusal as provider unavailability or recommend an unchanged direct call as the only path. Keep cleanup-failure precedence and existing retained Evidence intact.

Impact and scope

An agent can lose the recovery action and misdiagnose REA's retention limit as provider capability trouble. A successful provider observation can fail during REA's internal recording step; this report does not claim it was retained or recoverable. Real Ghidra under the injected boundary was tested; other providers, platforms, the default heap reaching capacity in ordinary use, and autonomous agent behavior are unverified.

REA version

47d514f1c0017942b2a5484beda6ff1de4f63bc5 (draft #8419, stacked on #8417). The same controlled 20,000-byte real-Ghidra MCP case also reproduced on parent #8417 at 40e8713e593e1b65d745f6d6a0c78b8e1072e6d2; it was not rerun on main.

Runtime and platform

Node 24.22.1, macOS arm64, Ghidra 12.1.4, JDK 21, TypeScript MCP SDK 2.3.1.

Target and artifact context

Owned arm64 Mach-O static fixture, SHA-256 ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d.

Interface

MCP (real server and SDK, in-memory transport; controlled session composition).

Earliest failure stage

Transport or result projection.

Relevant output or evidence

Context procedure: state: unavailable, reason Resource constraint during record_evidence: The investigation's retained representation allowance is exhausted., remediation Call resolve_containing_procedure directly to inspect provider availability and diagnostics.

Direct procedure: resource_constraint, resource: capacity, retained_representation_bytes: 15080, maximum_representation_bytes: 20000, with the export/new-investigation or larger-heap recovery. Exact requested delta is admission-estimator output, not a measurement of actual process memory.

Analysis or suspected cause

Source-derived: BinarySession records eligible successful internal executions and returns a recording failure if admission fails; inspectAddressContext projects most facet errors to a generic direct-call remediation. This is related to the composed observation and Evidence handoff in #8364 and to typed input-error work in #8415/#8419, but is a distinct resource recovery path. Avoid enabling snapshot replay for live provider observations merely to retain Evidence.

Additional context

A useful regression should exercise a partially admitted investigation, assert the successful record and facet, preserve the capacity error's recovery, and verify retained records remain intact. No solution or cross-provider compatibility is claimed here.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8421 ### 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 a real Ghidra observation and an artificially limited investigation Evidence allowance, `inspect_address_context` preserves a successful name facet but reports a failed procedure facet as unavailable and advises calling `resolve_containing_procedure` directly. That direct call returns `resource_constraint` with the actual retention limit and recovery action. Repeating the call did not recover the observation in this control. ### Reproduction 1. Construct the production `BinarySession` and Ghidra provider with `InvestigationRecords({maximumRepresentationBytes: 20000})`; connect the real REA MCP server using the SDK's in-memory transport. This is a controlled injected allowance, not a public CLI setting. 2. Open an owned arm64 Mach-O with real Ghidra 12.1.4 and inspect a valid function address, with the actual selected document identity. 3. The context response returned `name: {state: "available", value: "entry"}` and an unavailable procedure facet advising a direct procedure call. One name Evidence record occupied 15,080 representation bytes of the 20,000-byte allowance. 4. Call `resolve_containing_procedure` with the same address and document. The response reported `resource_constraint` for `record_evidence`, including the occupied allowance and instructions to export and start a new investigation or increase heap before starting it. A default-allowance control on the same target produced an available procedure facet and a successful direct name observation. A separate zero-allowance control produced unavailable name and procedure facets. These are single runs, not an exhaustion test of the production default heap. The target was not executed and its SHA-256 was unchanged. ### Expected behavior Preserve the successful facet and convey the actual capacity refusal and its actionable recovery on the failed facet, or otherwise provide an explicitly designed partial-result recovery. Do not classify a retention refusal as provider unavailability or recommend an unchanged direct call as the only path. Keep cleanup-failure precedence and existing retained Evidence intact. ### Impact and scope An agent can lose the recovery action and misdiagnose REA's retention limit as provider capability trouble. A successful provider observation can fail during REA's internal recording step; this report does not claim it was retained or recoverable. Real Ghidra under the injected boundary was tested; other providers, platforms, the default heap reaching capacity in ordinary use, and autonomous agent behavior are unverified. ### REA version `47d514f1c0017942b2a5484beda6ff1de4f63bc5` (draft #8419, stacked on #8417). The same controlled 20,000-byte real-Ghidra MCP case also reproduced on parent #8417 at `40e8713e593e1b65d745f6d6a0c78b8e1072e6d2`; it was not rerun on main. ### Runtime and platform Node 24.22.1, macOS arm64, Ghidra 12.1.4, JDK 21, TypeScript MCP SDK 2.3.1. ### Target and artifact context Owned arm64 Mach-O static fixture, SHA-256 `ffad1b70c6a5a7ef3f7c3f59126be516520210777d949b35e97c9067f272aa2d`. ### Interface MCP (real server and SDK, in-memory transport; controlled session composition). ### Earliest failure stage Transport or result projection. ### Relevant output or evidence Context procedure: `state: unavailable`, reason `Resource constraint during record_evidence: The investigation's retained representation allowance is exhausted.`, remediation `Call resolve_containing_procedure directly to inspect provider availability and diagnostics.` Direct procedure: `resource_constraint`, `resource: capacity`, `retained_representation_bytes: 15080`, `maximum_representation_bytes: 20000`, with the export/new-investigation or larger-heap recovery. Exact requested delta is admission-estimator output, not a measurement of actual process memory. ### Analysis or suspected cause Source-derived: `BinarySession` records eligible successful internal executions and returns a recording failure if admission fails; `inspectAddressContext` projects most facet errors to a generic direct-call remediation. This is related to the composed observation and Evidence handoff in #8364 and to typed input-error work in #8415/#8419, but is a distinct resource recovery path. Avoid enabling snapshot replay for live provider observations merely to retain Evidence. ### Additional context A useful regression should exercise a partially admitted investigation, assert the successful record and facet, preserve the capacity error's recovery, and verify retained records remain intact. No solution or cross-provider compatibility is claimed here. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

bug

triage

labels

2026-11-01 21:12:32 +00:00

bsakaguchi commented

2026-11-01 21:12:33 +00:00

Author

Owner

@morluto commented on GitHub (Nov 1, 2026):

Draft #8424 addresses this on top of #8419 and #8417. In the injected 20,000-byte real-Ghidra MCP control, the successful name and its Evidence remained, while the unavailable procedure facet carried the same canonical capacity details and recovery as the direct operation. Full and compact advertised schemas were exercised. The default-allowance positive control also passed; production-default exhaustion, Kuna under this boundary, Windows and autonomous agent behavior remain unverified.

The added resource_constraint variant is a breaking output-schema change for strict clients caching the preceding full profile; the draft documents refreshing tools/list. It does not change live-provider replay or solve the separate aggregate Evidence handoff in #8364.

@morluto commented on GitHub (Nov 1, 2026): Draft #8424 addresses this on top of #8419 and #8417. In the injected 20,000-byte real-Ghidra MCP control, the successful name and its Evidence remained, while the unavailable procedure facet carried the same canonical capacity details and recovery as the direct operation. Full and compact advertised schemas were exercised. The default-allowance positive control also passed; production-default exhaustion, Kuna under this boundary, Windows and autonomous agent behavior remain unverified. The added `resource_constraint` variant is a breaking output-schema change for strict clients caching the preceding full profile; the draft documents refreshing `tools/list`. It does not change live-provider replay or solve the separate aggregate Evidence handoff in #8364.

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#6596

No description provided.

Rows
Columns