morluto/rea

Fork 0

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

[GH-ISSUE #8276] [Bug] Unavailable load-image collections report zero-total empty page coverage #6519

New issue

Closed

opened 2026-11-01 21:11:51 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-11-01 21:11:51 +00:00

Owner

Originally created by @morluto on GitHub (Oct 31, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8276

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

A native-load-image page whose requested collection is unavailable reports items.rows: null, but its page coverage also reports status: empty, total: 0, and exhausted: true. The response does preserve verification_status: unsupported and an explicit unknown explaining that null rows mean unrecorded or inapplicable, not observed absence. The page metadata nevertheless has the same zero-total/exhausted values as an actually empty selection.

Reproduction

On macOS arm64, start the REA MCP server configured with Ghidra 12.1.4, open a self-built x86-64 ELF executable with open_binary, and call inspect_native_load_image with detail: summary. Its summary reported verification.status: unsupported, counts.sections: null, and counts.checks: null. Using its returned parent_evidence_id, call inspect_analysis_view with view: {kind: "native-load-image", collection: "sections", offset: 0, limit: 100}. Repeat with collection: "checks". Both returned rows: null and coverage {status: "empty", examined: 0, total: 0, next_offset: null, exhausted: true}.

As a control, the same parent had two observed relocations. Selecting collection: "relocations", indices: [] returned rows: [] and the identical coverage object. The binary was analyzed statically, its digest did not change, and it was not executed.

Expected behavior

Keep page selection and source availability distinguishable in structured coverage as well as in rows and prose. An unavailable collection should not acquire an indistinguishable zero-total/exhausted page outcome from a recorded empty selection. The exact representation can be decided in the shared view contract, preserving the useful difference between page coverage and producer coverage. The existing contract already states that null collections mean unrecorded or inapplicable.

Impact and scope

Agents and clients summarizing only coverage metadata can treat unavailable checks or sections as an exhausted empty set. No actual agent misinterpretation was measured, and the full response contains the null rows and caveat; this is conflicting structured signaling, not silent loss of the null. I reproduced this on the two named collections in one real Ghidra ELF session; other formats and views were not runtime-tested for this issue.

REA version

Runtime reproduction on source revision e6d0618979f0df3f1d5db218b0fc7b5e6a9cf3f9; source at 22e5aa97af8d726400f3f932cae10e0083412038 retains the same projection.

Runtime and platform

Node 24.22.1; macOS arm64; Ghidra 12.1.4 / JDK 21.

Target and artifact context

Self-built unexecuted x86-64 ELF PIE; Ghidra-backed load-image Evidence.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

The three coverage objects above are identical, while the first two items.rows are null and the control's rows are an empty array. The parent summary reported null checks/sections and two relocations. nativeLoadImageView.ts preserves null rows but calls selectRows(selected ?? [], view) before computing coverage; analysisViewCoverage.ts maps that empty page to total zero and exhausted. These are source-derived mechanics, not a claim of runtime verification at the newer revision.

Typed outcome or recovery expected

Expose whether the requested collection was recorded or applicable without requiring clients to infer it from prose; retain existing null and true empty distinctions.

Analysis or suspected cause

The projection substitutes an empty array only for paging, while preserving the original null in the items. Existing tests assert null rows and the separate empty-selection case, but do not assert availability-sensitive page metadata for null rows.

Additional context

The analysis occurred while evaluating the existing evidence workflow in #8221; this is a separate load-image view contract concern. Proposed validation: real MCP unrecorded versus recorded empty versus filtered/offset-exhausted controls, plus schema and existing clients; CLI and other formats remain untested.

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8276 ### 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 Evidence, artifacts, or reconstruction ### Observed behavior A `native-load-image` page whose requested collection is unavailable reports `items.rows: null`, but its page coverage also reports `status: empty`, `total: 0`, and `exhausted: true`. The response does preserve `verification_status: unsupported` and an explicit unknown explaining that null rows mean unrecorded or inapplicable, not observed absence. The page metadata nevertheless has the same zero-total/exhausted values as an actually empty selection. ### Reproduction On macOS arm64, start the REA MCP server configured with Ghidra 12.1.4, open a self-built x86-64 ELF executable with `open_binary`, and call `inspect_native_load_image` with `detail: summary`. Its summary reported `verification.status: unsupported`, `counts.sections: null`, and `counts.checks: null`. Using its returned `parent_evidence_id`, call `inspect_analysis_view` with `view: {kind: "native-load-image", collection: "sections", offset: 0, limit: 100}`. Repeat with `collection: "checks"`. Both returned `rows: null` and coverage `{status: "empty", examined: 0, total: 0, next_offset: null, exhausted: true}`. As a control, the same parent had two observed relocations. Selecting `collection: "relocations", indices: []` returned `rows: []` and the identical coverage object. The binary was analyzed statically, its digest did not change, and it was not executed. ### Expected behavior Keep page selection and source availability distinguishable in structured coverage as well as in `rows` and prose. An unavailable collection should not acquire an indistinguishable zero-total/exhausted page outcome from a recorded empty selection. The exact representation can be decided in the shared view contract, preserving the useful difference between page coverage and producer coverage. The existing contract already states that null collections mean unrecorded or inapplicable. ### Impact and scope Agents and clients summarizing only coverage metadata can treat unavailable checks or sections as an exhausted empty set. No actual agent misinterpretation was measured, and the full response contains the null rows and caveat; this is conflicting structured signaling, not silent loss of the null. I reproduced this on the two named collections in one real Ghidra ELF session; other formats and views were not runtime-tested for this issue. ### REA version Runtime reproduction on source revision `e6d0618979f0df3f1d5db218b0fc7b5e6a9cf3f9`; source at `22e5aa97af8d726400f3f932cae10e0083412038` retains the same projection. ### Runtime and platform Node 24.22.1; macOS arm64; Ghidra 12.1.4 / JDK 21. ### Target and artifact context Self-built unexecuted x86-64 ELF PIE; Ghidra-backed load-image Evidence. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence The three coverage objects above are identical, while the first two `items.rows` are null and the control's rows are an empty array. The parent summary reported null checks/sections and two relocations. [`nativeLoadImageView.ts`](https://github.com/morluto/rea/blob/22e5aa97af8d726400f3f932cae10e0083412038/src/domain/analysisView/nativeLoadImageView.ts) preserves null rows but calls `selectRows(selected ?? [], view)` before computing coverage; [`analysisViewCoverage.ts`](https://github.com/morluto/rea/blob/22e5aa97af8d726400f3f932cae10e0083412038/src/domain/analysisView/analysisViewCoverage.ts) maps that empty page to total zero and exhausted. These are source-derived mechanics, not a claim of runtime verification at the newer revision. ### Typed outcome or recovery expected Expose whether the requested collection was recorded or applicable without requiring clients to infer it from prose; retain existing null and true empty distinctions. ### Analysis or suspected cause The projection substitutes an empty array only for paging, while preserving the original null in the items. Existing tests assert null rows and the separate empty-selection case, but do not assert availability-sensitive page metadata for null rows. ### Additional context The analysis occurred while evaluating the existing evidence workflow in #8221; this is a separate load-image view contract concern. Proposed validation: real MCP unrecorded versus recorded empty versus filtered/offset-exhausted controls, plus schema and existing clients; CLI and other formats remain untested.

bsakaguchi added the

bug

triage

labels

2026-11-01 21:11:51 +00:00

bsakaguchi commented

2026-11-01 21:11:52 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the REA tool-design investigation.

bsakaguchi commented

2026-11-01 21:11:52 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Related control on native observation views, using real Ghidra 12.1.4 and Kuna 1.986 through REA MCP on the same owned Mach-O: procedure_callees followed by inspect_analysis_view with view: {kind: "native-context", facet: "result-limitations"} returned rows: null, result_limitation_count: null, and an explicit unknown saying the facet is not applicable to this primitive. Its page coverage nevertheless reported {status: "complete-within-view", examined: 0, total: 0, next_offset: null, exhausted: true}. This is a different status from the load-image case; the null and its meaning are preserved in the response.

Control: for get_call_graph on the same function, the corresponding facet returned recorded limitation rows and actual totals (six with Ghidra, three with Kuna); an offset past the end returned rows: [] and an empty page with the recorded total retained. Thus page completion, result applicability, and source counts are distinct. This is one target and host; no agent behavior was measured. The target digest was unchanged.

Source at current main 22e5aa97af8d726400f3f932cae10e0083412038 explicitly maps a null result-limitations total to completeWithinViewCoverage(0, 0) in nativeObservationView.ts. Consider this adjacent case when evaluating the shared coverage representation; it may warrant separate tracking if the native-context contract should remain independent.

@morluto commented on GitHub (Oct 31, 2026): Related control on native observation views, using real Ghidra 12.1.4 and Kuna 1.986 through REA MCP on the same owned Mach-O: `procedure_callees` followed by `inspect_analysis_view` with `view: {kind: "native-context", facet: "result-limitations"}` returned `rows: null`, `result_limitation_count: null`, and an explicit unknown saying the facet is not applicable to this primitive. Its page coverage nevertheless reported `{status: "complete-within-view", examined: 0, total: 0, next_offset: null, exhausted: true}`. This is a different status from the load-image case; the null and its meaning are preserved in the response. Control: for `get_call_graph` on the same function, the corresponding facet returned recorded limitation rows and actual totals (six with Ghidra, three with Kuna); an offset past the end returned `rows: []` and an empty page with the recorded total retained. Thus page completion, result applicability, and source counts are distinct. This is one target and host; no agent behavior was measured. The target digest was unchanged. Source at current main `22e5aa97af8d726400f3f932cae10e0083412038` explicitly maps a null result-limitations total to `completeWithinViewCoverage(0, 0)` in [`nativeObservationView.ts`](https://github.com/morluto/rea/blob/22e5aa97af8d726400f3f932cae10e0083412038/src/domain/analysisView/nativeObservationView.ts). Consider this adjacent case when evaluating the shared coverage representation; it may warrant separate tracking if the native-context contract should remain independent.

bsakaguchi commented

2026-11-01 21:11:52 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

A related but distinct native-function control on REA 60149282: real Kuna 1.986 analyze_function(detail: summary) for a function with two observed address-only xrefs reported incoming_references: null and references.available: false. Its inspect_analysis_view for incoming_references returned an unavailable status object, an explicit unknown, and coverage complete-within-view / examined: 1 / total: 1 / exhausted: true at offsets 0, 2, and 99. Here the one examined item is the status object, not a reported reference; this is not the same zero-total/null-row path described in the issue.

As a control, real Ghidra 12.1.4 on the same unexecuted ELF reported four typed incoming references: limit 2 at offsets 0 and 2 returned two rows per page, and offset 99 returned an empty page with total 4. The target digest was unchanged. The status object and unknown are available to the caller; no actual agent confusion was measured. When addressing this issue, consider how clients distinguish coverage of a status item from coverage of an unavailable reference collection, including the nonzero-offset behavior, without equating the two implementations. Related workflow discussion: #8348.

@morluto commented on GitHub (Oct 31, 2026): A related but distinct native-function control on REA `60149282`: real Kuna 1.986 `analyze_function(detail: summary)` for a function with two observed address-only xrefs reported `incoming_references: null` and `references.available: false`. Its `inspect_analysis_view` for `incoming_references` returned an **unavailable status object**, an explicit unknown, and coverage `complete-within-view / examined: 1 / total: 1 / exhausted: true` at offsets 0, 2, and 99. Here the one examined item is the status object, not a reported reference; this is not the same zero-total/null-row path described in the issue. As a control, real Ghidra 12.1.4 on the same unexecuted ELF reported four typed incoming references: limit 2 at offsets 0 and 2 returned two rows per page, and offset 99 returned an empty page with total 4. The target digest was unchanged. The status object and unknown are available to the caller; no actual agent confusion was measured. When addressing this issue, consider how clients distinguish coverage of a status item from coverage of an unavailable reference collection, including the nonzero-offset behavior, without equating the two implementations. Related workflow discussion: #8348.

bsakaguchi commented

2026-11-01 21:11:52 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Real-provider validation of PR #8291 is recorded at https://github.com/morluto/rea/pull/8291#issuecomment-6547462098. The unavailable load-image and native-context cases changed as intended, while recorded empty and paginated controls stayed stable. Historical views from those real observations remained accepted. The separate Kuna native incoming-reference status-object behavior reported above remains unchanged and outside that PR's stated scope.

@morluto commented on GitHub (Oct 31, 2026): Real-provider validation of PR #8291 is recorded at https://github.com/morluto/rea/pull/8291#issuecomment-6547462098. The unavailable load-image and native-context cases changed as intended, while recorded empty and paginated controls stayed stable. Historical views from those real observations remained accepted. The separate Kuna native incoming-reference status-object behavior reported above remains unchanged and outside that PR's stated scope.

bsakaguchi closed this issue

2026-11-04 16:17:37 +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#6519

No description provided.

Rows
Columns