morluto/rea

Fork 0

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

[GH-ISSUE #8760] [Design] Guide retained-Evidence recovery for oversized matching inputs #7535

New issue

Closed

opened 2026-11-03 09:20:09 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 09:20:09 +00:00

Owner

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

Before submitting

I searched open and closed issues for a related report.
I removed credentials, tokens and private target data.

Area

MCP tool contracts and recovery

Observed behavior

A match_native_functions request with two valid inline inventories, two complete function dossiers and two byte observations exceeded the MCP 1,024-element argument allowance before schema validation. Its error recommended reducing combined elements or restarting REA with a larger allowance, but did not mention the supported retained-Evidence reference form. The same complete inputs succeeded after exporting/importing the source Evidence and replacing the six inline records with retained references.

Reproduction

On REA main 9ebbe67e05af08b567e215340da993c08dae378f, macOS arm64, Node 24.22.1 and Ghidra 12.1.4:

Build two source-owned stripped x86-64 ELF programs with the same two functions, changing one immediate in the second program. Do not execute them.
Through real stdio MCP, separately open each binary, call list_procedures, analyze_function with detail: complete for the corresponding function, and read_bytes for its complete 13-byte body. Export each session Evidence bundle before closing the target.
Call match_native_functions with the two inventory Evidence objects inline as left and right, and the respective dossier and byte Evidence objects inline in left_observations and right_observations. In the compact profile the tool returns resource_constraint, resource: transport, max_input_elements: 1024; schema validation and execution did not start. Remediation says to reduce combined array elements/object members or increase REA_MCP_MAX_INPUT_ELEMENTS.
Import both bundles and repeat using {kind: "retained-evidence", evidence_id: ...} for each of the same six records. The comparison succeeds in both compact and full MCP profiles, pairs the selected entry by reported name with different body hashes, and retains a compare_functions handoff. This preserves the supplied observations rather than dropping them.

The target SHA-256 values stayed 0cee46f9e95af174dec7f281c179cbe5233348520302c69fdc9eafc7fcebff1d and 1f24b3a90503fd978b540379c05b46726e5ff911d0f1b42955660765fe998b96. The failed inline request was exercised in compact only; the retained-reference retry was exercised in compact and full. The requests were scripted public-tool calls, not an autonomous-agent trial. The server's bounded admission itself is not challenged by this report.

Expected behavior

When an operation supports a retained-reference form, offer that applicable recovery when inline Evidence exceeds the input allowance, including how to retain/import it if necessary. Avoid suggesting that discarding observations is the only bounded option, and avoid recommending retained IDs when the relevant Evidence was not retained. Keep the generic allowance and restart options accurate for other operations; consider whether the hint belongs in the operation contract or a shared admission recovery mechanism.

Impact and scope

A caller can preserve the same evidence without raising the limit, but the error does not make that path visible. This is one real-provider workflow; other clients, operations and agent choices were not measured.

REA version

9ebbe67e05af08b567e215340da993c08dae378f.

Runtime and platform

Node 24.22.1, macOS arm64, Ghidra 12.1.4, stdio MCP compact and full schema profiles.

Target and artifact context

Two unexecuted, source-built ELF fixtures; caller-owned exported Evidence bundles.

Interface

MCP.

Earliest failure stage

Transport argument admission, before schema validation.

Relevant output or evidence

Error reports resource_constraint, resource: transport, and max_input_elements: 1024. The retained-reference retry succeeded with the same six source records; exact byte observations differed at the intended immediate.

Typed outcome or recovery expected

Conditional retained-Evidence guidance that respects whether source records exist and preserves the fixed input bound.

Analysis or suspected cause

The generic transport admission rejects oversized argument structures before the operation handler can explain its typed reference alternatives. The appropriate owner and safe applicability of operation-specific guidance require investigation.

Additional context

Related to #7189's identification workflow and #8427's unretained-Evidence recovery. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Same-server direct retained-reference control

In separate real Ghidra 12.1.4 stdio MCP runs on the same two fixtures and main 9ebbe67e, I collected the same two inventories, dossiers and byte observations, closed each binary, and called match_native_functions using the six retained-Evidence IDs directly in the same server, without exporting or importing bundles. The comparison succeeded in compact and full profiles and retained the distinct body hashes and partial source-coverage status. The fixture digests were unchanged. Thus, when the records are already retained in the current server, direct references are a shorter tested recovery; exporting and importing the originating bundles is relevant to a different server or missing retained closure, not mandatory for this workflow.

Source inspection: the shared server converts the SDK's element-count refusal before schema validation, without reparsing the oversized arguments. A contract-aware recovery needs to identify supported reference forms without assuming any particular record is retained or inspecting an unbounded rejected payload; operations that do not accept Evidence references still need generic limit advice. This is design analysis, not a claim that a particular metadata mechanism is implemented.

Existing contract guidance and deferred-server constraint

Real stdio tools/list on main 9ebbe67e advertised the exact retained-Evidence form and parent_evidence_id guidance in match_native_functions and find_changed_behavior input-schema descriptions for both compact and full input schema profiles. The read_bytes control had no such Evidence-input description. This is existing catalog guidance; the observed input-limit error did not repeat it. The earlier failed-call control used the compact input profile; successful retained-reference calls were tested with compact and full output schema profiles.

Source inspection: getEvidenceInputContract already derives hasEvidence from canonical declared/borrowed Evidence schemas, and toolInputSchemaWithMetadata uses that fact to generate the advertised guidance. toolRegistrationOptions wraps the canonical schema for SDK validation. The deferred server can reject an over-budget request using the recorded catalog before initializing the canonical runtime, so a fix that consults only the live Zod contract after lazy initialization would miss that path. Consider carrying a contract-derived, non-sensitive recovery fact through the recorded registration or another owner-preserving mechanism; do not infer applicability by searching rejected arguments, hand-maintain an independent operation list, or parse human-readable descriptions as authority. Confirm that hasEvidence covers the particular supported reference form before using it as an exact recovery promise; imported/nonretained closure and other source forms remain distinct.

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8760 ### Before submitting - [x] I searched open and closed issues for a related report. - [x] I removed credentials, tokens and private target data. ### Area MCP tool contracts and recovery ### Observed behavior A `match_native_functions` request with two valid inline inventories, two complete function dossiers and two byte observations exceeded the MCP 1,024-element argument allowance before schema validation. Its error recommended reducing combined elements or restarting REA with a larger allowance, but did not mention the supported retained-Evidence reference form. The same complete inputs succeeded after exporting/importing the source Evidence and replacing the six inline records with retained references. ### Reproduction On REA main `9ebbe67e05af08b567e215340da993c08dae378f`, macOS arm64, Node 24.22.1 and Ghidra 12.1.4: 1. Build two source-owned stripped x86-64 ELF programs with the same two functions, changing one immediate in the second program. Do not execute them. 2. Through real stdio MCP, separately open each binary, call `list_procedures`, `analyze_function` with `detail: complete` for the corresponding function, and `read_bytes` for its complete 13-byte body. Export each session Evidence bundle before closing the target. 3. Call `match_native_functions` with the two inventory Evidence objects inline as `left` and `right`, and the respective dossier and byte Evidence objects inline in `left_observations` and `right_observations`. In the compact profile the tool returns `resource_constraint`, `resource: transport`, `max_input_elements: 1024`; schema validation and execution did not start. Remediation says to reduce combined array elements/object members or increase `REA_MCP_MAX_INPUT_ELEMENTS`. 4. Import both bundles and repeat using `{kind: "retained-evidence", evidence_id: ...}` for each of the same six records. The comparison succeeds in both compact and full MCP profiles, pairs the selected entry by reported name with different body hashes, and retains a `compare_functions` handoff. This preserves the supplied observations rather than dropping them. The target SHA-256 values stayed `0cee46f9e95af174dec7f281c179cbe5233348520302c69fdc9eafc7fcebff1d` and `1f24b3a90503fd978b540379c05b46726e5ff911d0f1b42955660765fe998b96`. The failed inline request was exercised in compact only; the retained-reference retry was exercised in compact and full. The requests were scripted public-tool calls, not an autonomous-agent trial. The server's bounded admission itself is not challenged by this report. ### Expected behavior When an operation supports a retained-reference form, offer that applicable recovery when inline Evidence exceeds the input allowance, including how to retain/import it if necessary. Avoid suggesting that discarding observations is the only bounded option, and avoid recommending retained IDs when the relevant Evidence was not retained. Keep the generic allowance and restart options accurate for other operations; consider whether the hint belongs in the operation contract or a shared admission recovery mechanism. ### Impact and scope A caller can preserve the same evidence without raising the limit, but the error does not make that path visible. This is one real-provider workflow; other clients, operations and agent choices were not measured. ### REA version `9ebbe67e05af08b567e215340da993c08dae378f`. ### Runtime and platform Node 24.22.1, macOS arm64, Ghidra 12.1.4, stdio MCP compact and full schema profiles. ### Target and artifact context Two unexecuted, source-built ELF fixtures; caller-owned exported Evidence bundles. ### Interface MCP. ### Earliest failure stage Transport argument admission, before schema validation. ### Relevant output or evidence Error reports `resource_constraint`, `resource: transport`, and `max_input_elements: 1024`. The retained-reference retry succeeded with the same six source records; exact byte observations differed at the intended immediate. ### Typed outcome or recovery expected Conditional retained-Evidence guidance that respects whether source records exist and preserves the fixed input bound. ### Analysis or suspected cause The generic transport admission rejects oversized argument structures before the operation handler can explain its typed reference alternatives. The appropriate owner and safe applicability of operation-specific guidance require investigation. ### Additional context Related to #7189's identification workflow and #8427's unretained-Evidence recovery. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Same-server direct retained-reference control In separate real Ghidra 12.1.4 stdio MCP runs on the same two fixtures and main `9ebbe67e`, I collected the same two inventories, dossiers and byte observations, closed each binary, and called `match_native_functions` using the six retained-Evidence IDs directly in the same server, without exporting or importing bundles. The comparison succeeded in compact and full profiles and retained the distinct body hashes and partial source-coverage status. The fixture digests were unchanged. Thus, when the records are already retained in the current server, direct references are a shorter tested recovery; exporting and importing the originating bundles is relevant to a different server or missing retained closure, not mandatory for this workflow. Source inspection: the shared server converts the SDK's element-count refusal before schema validation, without reparsing the oversized arguments. A contract-aware recovery needs to identify supported reference forms without assuming any particular record is retained or inspecting an unbounded rejected payload; operations that do not accept Evidence references still need generic limit advice. This is design analysis, not a claim that a particular metadata mechanism is implemented. ### Existing contract guidance and deferred-server constraint Real stdio `tools/list` on main `9ebbe67e` advertised the exact retained-Evidence form and `parent_evidence_id` guidance in `match_native_functions` and `find_changed_behavior` input-schema descriptions for both compact and full **input** schema profiles. The `read_bytes` control had no such Evidence-input description. This is existing catalog guidance; the observed input-limit error did not repeat it. The earlier failed-call control used the compact input profile; successful retained-reference calls were tested with compact and full **output** schema profiles. Source inspection: `getEvidenceInputContract` already derives `hasEvidence` from canonical declared/borrowed Evidence schemas, and `toolInputSchemaWithMetadata` uses that fact to generate the advertised guidance. `toolRegistrationOptions` wraps the canonical schema for SDK validation. The deferred server can reject an over-budget request using the recorded catalog before initializing the canonical runtime, so a fix that consults only the live Zod contract after lazy initialization would miss that path. Consider carrying a contract-derived, non-sensitive recovery fact through the recorded registration or another owner-preserving mechanism; do not infer applicability by searching rejected arguments, hand-maintain an independent operation list, or parse human-readable descriptions as authority. Confirm that `hasEvidence` covers the particular supported reference form before using it as an exact recovery promise; imported/nonretained closure and other source forms remain distinct.

bsakaguchi closed this issue

2026-11-04 20:25:27 +00:00

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

No description provided.

Rows
Columns