morluto/rea

Fork 0

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

[GH-ISSUE #8416] [Bug] Address context can hide incomplete facet cleanup #6595

New issue

Closed

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/8416

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

In a controlled application-boundary experiment, inspectAddressContext hid incomplete cleanup on failed facet operations. This is a simulated provider, not a reproduced Ghidra or Kuna cleanup failure.

Reproduction

On REA 6e9ee97a, call the shared inspectAddressContext workflow with a controlled AnalysisOperationPort:

Let address_name and containing-function resolution succeed, and return separate AnalysisCapabilityUnavailableError values for comment and inline_comment, each with cleanup naming a different owned-resource sentinel.
The standalone projection of either error is cleanup_incomplete, and both error objects remain cleanup-incomplete. The aggregate nevertheless returned success with unavailable facets and neither resource nor cleanup failure in its result.
In a second run, make containing-function resolution return AnalysisCancelledError while those two cleanup errors remain. The workflow returned a plain cancelled error with cleanupIncomplete: false, omitting both cleanup-resource sentinels.

A separate single-error control on draft #8414 showed the same successful aggregate and missing cleanup attribution, with its new function-dossier recovery text. No real resources were launched or cleaned up by this simulation.

Expected behavior

Do not discard unresolved cleanup ownership when composing parallel results. Preserve the primary cancellation/failure, each still-owned resource and the actual cleanup/retry state, including when more than one facet has incomplete cleanup. Maintain valid partial observations and ordinary facet-local capability outcomes as appropriate. Test owner release and retry; do not assume a successful sibling proves cleanup complete.

Impact and scope

The application boundary can report success or plain cancellation while its inputs carry unresolved cleanup failures. Whether a real Ghidra, Kuna, Hopper or other provider produces these exact simultaneous outcomes here is unknown. Session-level cleanup ownership and end-to-end resource retry were not exercised in this controlled experiment; this report does not claim a real resource leak.

REA version

6e9ee97a69cb16c7150d8b550e705cba055ee4f0; single-failure candidate control on draft #8414 a3f0b22d2.

Runtime and platform

Node 24.22.1, macOS arm64; simulated AnalysisOperationPort.

Target and artifact context

Synthetic in-memory operation results, no target execution or real process.

Interface

Shared application workflow invoked directly; public MCP reproduction not yet performed.

Earliest failure stage

Cleanup, cancellation, or lifecycle.

Relevant output or evidence

Without cancellation, direct projection was cleanup_incomplete while the context result was ok: true. With cancellation plus two incomplete cleanup errors, the result was cancelled with cleanupIncomplete: false; neither reported the two controlled resource names.

Typed outcome or recovery expected

A typed outcome preserving all cleanup owners and their live completion status, with cancellation and other primary errors retained. A passing test should exercise independent owner releases and a real retry where the production owner has one.

Analysis or suspected cause

Source-derived: inspectAddressContext runs five facets with Promise.all, returns the first cancellation, timeout or no-target error, and degrades all other errors to text-only facets. It does not inspect cleanupIncomplete or combine cleanup-bearing errors. A fix must account for all settled child outcomes and their owners, rather than checking only the first failure.

Additional context

Related #8415 concerns loss of typed input diagnostics; #8364 concerns Evidence handoff. Last known good: NOT_ENOUGH_INFO.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8416 ### 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 In a controlled application-boundary experiment, `inspectAddressContext` hid incomplete cleanup on failed facet operations. This is a simulated provider, not a reproduced Ghidra or Kuna cleanup failure. ### Reproduction On REA `6e9ee97a`, call the shared `inspectAddressContext` workflow with a controlled `AnalysisOperationPort`: 1. Let `address_name` and containing-function resolution succeed, and return separate `AnalysisCapabilityUnavailableError` values for `comment` and `inline_comment`, each with `cleanup` naming a different owned-resource sentinel. 2. The standalone projection of either error is `cleanup_incomplete`, and both error objects remain cleanup-incomplete. The aggregate nevertheless returned success with unavailable facets and neither resource nor cleanup failure in its result. 3. In a second run, make containing-function resolution return `AnalysisCancelledError` while those two cleanup errors remain. The workflow returned a plain cancelled error with `cleanupIncomplete: false`, omitting both cleanup-resource sentinels. A separate single-error control on draft #8414 showed the same successful aggregate and missing cleanup attribution, with its new function-dossier recovery text. No real resources were launched or cleaned up by this simulation. ### Expected behavior Do not discard unresolved cleanup ownership when composing parallel results. Preserve the primary cancellation/failure, each still-owned resource and the actual cleanup/retry state, including when more than one facet has incomplete cleanup. Maintain valid partial observations and ordinary facet-local capability outcomes as appropriate. Test owner release and retry; do not assume a successful sibling proves cleanup complete. ### Impact and scope The application boundary can report success or plain cancellation while its inputs carry unresolved cleanup failures. Whether a real Ghidra, Kuna, Hopper or other provider produces these exact simultaneous outcomes here is unknown. Session-level cleanup ownership and end-to-end resource retry were not exercised in this controlled experiment; this report does not claim a real resource leak. ### REA version `6e9ee97a69cb16c7150d8b550e705cba055ee4f0`; single-failure candidate control on draft #8414 `a3f0b22d2`. ### Runtime and platform Node 24.22.1, macOS arm64; simulated `AnalysisOperationPort`. ### Target and artifact context Synthetic in-memory operation results, no target execution or real process. ### Interface Shared application workflow invoked directly; public MCP reproduction not yet performed. ### Earliest failure stage Cleanup, cancellation, or lifecycle. ### Relevant output or evidence Without cancellation, direct projection was `cleanup_incomplete` while the context result was `ok: true`. With cancellation plus two incomplete cleanup errors, the result was `cancelled` with `cleanupIncomplete: false`; neither reported the two controlled resource names. ### Typed outcome or recovery expected A typed outcome preserving all cleanup owners and their live completion status, with cancellation and other primary errors retained. A passing test should exercise independent owner releases and a real retry where the production owner has one. ### Analysis or suspected cause Source-derived: [`inspectAddressContext`](https://github.com/morluto/rea/blob/6e9ee97a69cb16c7150d8b550e705cba055ee4f0/src/application/AnalysisContextQueries.ts) runs five facets with `Promise.all`, returns the first cancellation, timeout or no-target error, and degrades all other errors to text-only facets. It does not inspect `cleanupIncomplete` or combine cleanup-bearing errors. A fix must account for all settled child outcomes and their owners, rather than checking only the first failure. ### Additional context Related #8415 concerns loss of typed input diagnostics; #8364 concerns Evidence handoff. Last known good: NOT_ENOUGH_INFO. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi

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

closed this issue
added the
bug

triage
labels

bsakaguchi commented

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

Author

Owner

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

Draft #8417 now covers this at the shared workflow and MCP boundaries. The new MCP regression fails on main for both success-with-hidden-cleanup and cancellation-with-hidden-cleanup, and passes on the candidate. Controlled leases exercise two owners, failed retry and independent successful release; cancellation controls cover late provider completion and preserve earlier failure ordering. Real Ghidra and Kuna checks were normal-operation controls only; an actual provider cleanup failure and its session-owned retry remain unverified. The related guidance PR #8414 overlaps these files and needs coordinated integration.

@morluto commented on GitHub (Nov 1, 2026): Draft #8417 now covers this at the shared workflow and MCP boundaries. The new MCP regression fails on main for both success-with-hidden-cleanup and cancellation-with-hidden-cleanup, and passes on the candidate. Controlled leases exercise two owners, failed retry and independent successful release; cancellation controls cover late provider completion and preserve earlier failure ordering. Real Ghidra and Kuna checks were normal-operation controls only; an actual provider cleanup failure and its session-owned retry remain unverified. The related guidance PR #8414 overlaps these files and needs coordinated integration.

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

No description provided.

Rows
Columns