morluto/rea

Fork 0

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

[GH-ISSUE #8353] [Bug] Session availability suggests opening a target while owned cleanup blocks it #6561

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

MCP or agent integration

Observed behavior

After close_binary retires a Kuna target but retains unconfirmed cleanup, binary_session correctly reports open: false and cleanup_pending: true. Its tool_availability group for procedure_assembly nevertheless says target_required and “Call open_binary with a supported local target.” An immediate open_binary of another supported target returned cleanup_incomplete and the generic resource-review advice. The earlier close error did correctly offer the same-connection close_binary cleanup retry after #8329.

Reproduction

On macOS arm64 / real Kuna 1.986 / REA d54a4661, I used a caller-owned wrapper that creates a start marker and sleeps 30 seconds before forwarding decompile-project to Kuna. With a fresh isolated cache:

Open an owned Mach-O, start procedure_assembly, wait for the wrapper marker, and cancel the only waiter.
close_binary returns cleanup_incomplete with recovery: {kind:"retry_cleanup", operation:"close_binary"} because macOS withheld ownership information for two still-live candidates.
binary_session({detail:"summary"}) reports open:false, cleanup_pending:true, and a procedure_assembly group with reason:"target_required" and remediation to call open_binary. Immediately opening a different supported ELF returns cleanup_incomplete, with generic resource-review remediation and no cleanup retry hint.
A second immediate close_binary remains incomplete and retains its retry offer. After the controlled delay, close_binary succeeds; status reports no pending cleanup, and opening the ELF and resolving its procedure succeeds.

This is one deliberately delayed run, not a natural-frequency claim. The provider's captured process identity remained unknown until cleanup could be confirmed; no unverified process was terminated by the caller.

Expected behavior

When the session knows a retained cleanup owner blocks a new target and knows that same-connection cleanup retry is supported, expose that prerequisite in session status or the relevant availability guidance before directing an agent to open a target. Keep the no-target guidance after cleanup settles. Do not infer that all cleanup_pending owners can be retried by close_binary: external-mutation and other owners can have different recovery and must retain their own semantics.

Impact and scope

An agent consulting status after losing or overlooking the earlier close error receives an incomplete next step and, if it follows it immediately in this case, a second generic error. The status's top-level pending flag and the first close error remain accurate; no actual agent behavior or infinite retry was measured. Other providers, owner combinations and platforms are untested. open_binary may itself settle cleanup after the condition resolves, as tested separately in #8211, so the issue concerns guidance during this observed blocked interval, not a claim that open can never recover.

REA version

d54a4661da20382ad8456564a08569fdd24131c5 after merged #8329.

Runtime and platform

Node 24.22.1; macOS arm64; Kuna 1.986 behind a controlled wrapper; TypeScript MCP SDK 2.3.1.

Target and artifact context

Owned 1,200-function arm64 Mach-O and a separate owned x86-64 ELF; isolated Kuna cache. Both SHA-256 hashes unchanged; neither target ran.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

First and repeated close errors carried retry_cleanup; immediate open returned cleanup_incomplete without recovery; the status target-dependent group remained target_required before and after the blocked open. cleanup_pending changed to false after successful close and isolated staging/projects were empty. SDK validated successful responses against fetched compact schemas; all three error projections separately validated against the published draft-2020-12 error schema.

Typed outcome or recovery expected

State the relevant owned-cleanup prerequisite and conditional retry only when established by its owner; do not promise success, lose resource details, or treat the failed analysis as retryable.

Analysis or suspected cause

Source-derived: targetAvailability sees target-open and capability facts and emits the same target-required remediation for a closed session. Its availability context does not include the retained cleanup owner's supported recovery. The broader cleanup_pending status includes more than the session-owned close retry, so a blanket rule on that boolean would be unsafe.

Additional context

Follow-up to closed #8211 and merged #8329. The real-provider validation confirms the close-specific fix and its limits. Related closed #6091 addresses reporting external-mutation reopen blockers. The existing public MCP regression in #8329 uses a simulated Kuna launcher; this report concerns status guidance after a real-provider controlled stop.

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8353 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Observed behavior After `close_binary` retires a Kuna target but retains unconfirmed cleanup, `binary_session` correctly reports `open: false` and `cleanup_pending: true`. Its `tool_availability` group for `procedure_assembly` nevertheless says `target_required` and “Call open_binary with a supported local target.” An immediate `open_binary` of another supported target returned `cleanup_incomplete` and the generic resource-review advice. The earlier close error did correctly offer the same-connection `close_binary` cleanup retry after #8329. ### Reproduction On macOS arm64 / real Kuna 1.986 / REA `d54a4661`, I used a caller-owned wrapper that creates a start marker and sleeps 30 seconds before forwarding `decompile-project` to Kuna. With a fresh isolated cache: 1. Open an owned Mach-O, start `procedure_assembly`, wait for the wrapper marker, and cancel the only waiter. 2. `close_binary` returns `cleanup_incomplete` with `recovery: {kind:"retry_cleanup", operation:"close_binary"}` because macOS withheld ownership information for two still-live candidates. 3. `binary_session({detail:"summary"})` reports `open:false`, `cleanup_pending:true`, and a `procedure_assembly` group with `reason:"target_required"` and remediation to call `open_binary`. Immediately opening a different supported ELF returns `cleanup_incomplete`, with generic resource-review remediation and no cleanup retry hint. 4. A second immediate `close_binary` remains incomplete and retains its retry offer. After the controlled delay, `close_binary` succeeds; status reports no pending cleanup, and opening the ELF and resolving its procedure succeeds. This is one deliberately delayed run, not a natural-frequency claim. The provider's captured process identity remained unknown until cleanup could be confirmed; no unverified process was terminated by the caller. ### Expected behavior When the session knows a retained cleanup owner blocks a new target and knows that same-connection cleanup retry is supported, expose that prerequisite in session status or the relevant availability guidance before directing an agent to open a target. Keep the no-target guidance after cleanup settles. Do not infer that all `cleanup_pending` owners can be retried by `close_binary`: external-mutation and other owners can have different recovery and must retain their own semantics. ### Impact and scope An agent consulting status after losing or overlooking the earlier close error receives an incomplete next step and, if it follows it immediately in this case, a second generic error. The status's top-level pending flag and the first close error remain accurate; no actual agent behavior or infinite retry was measured. Other providers, owner combinations and platforms are untested. `open_binary` may itself settle cleanup after the condition resolves, as tested separately in #8211, so the issue concerns guidance during this observed blocked interval, not a claim that open can never recover. ### REA version `d54a4661da20382ad8456564a08569fdd24131c5` after merged #8329. ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.986 behind a controlled wrapper; TypeScript MCP SDK 2.3.1. ### Target and artifact context Owned 1,200-function arm64 Mach-O and a separate owned x86-64 ELF; isolated Kuna cache. Both SHA-256 hashes unchanged; neither target ran. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence First and repeated close errors carried `retry_cleanup`; immediate open returned `cleanup_incomplete` without `recovery`; the status target-dependent group remained `target_required` before and after the blocked open. `cleanup_pending` changed to false after successful close and isolated staging/projects were empty. SDK validated successful responses against fetched compact schemas; all three error projections separately validated against the published draft-2020-12 error schema. ### Typed outcome or recovery expected State the relevant owned-cleanup prerequisite and conditional retry only when established by its owner; do not promise success, lose resource details, or treat the failed analysis as retryable. ### Analysis or suspected cause Source-derived: [`targetAvailability`](https://github.com/morluto/rea/blob/d54a4661da20382ad8456564a08569fdd24131c5/src/application/CapabilityInventory.ts) sees target-open and capability facts and emits the same target-required remediation for a closed session. Its availability context does not include the retained cleanup owner's supported recovery. The broader `cleanup_pending` status includes more than the session-owned close retry, so a blanket rule on that boolean would be unsafe. ### Additional context Follow-up to closed #8211 and merged #8329. The [real-provider validation](https://github.com/morluto/rea/pull/8329#issuecomment-6547349218) confirms the close-specific fix and its limits. Related closed #6091 addresses reporting external-mutation reopen blockers. The existing public MCP regression in #8329 uses a simulated Kuna launcher; this report concerns status guidance after a real-provider controlled stop. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

bsakaguchi added the

bug

triage

labels

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

bsakaguchi closed this issue

2026-11-03 00:29:58 +00:00

bsakaguchi commented

2026-11-03 00:30:00 +00:00

Author

Owner

@xu91102 commented on GitHub (Nov 2, 2026):

I reproduced the status-guidance gap on current main 8250bf2320ea57aab4e664db4b4d44b8abd2004e, with the actual compiled stdio MCP server, official unmodified Kuna 1.988/macOS arm64, and an owned clang-built Mach-O. The target was never executed and its SHA-256 stayed unchanged.

This is a different controlled cleanup condition from the report's withheld process identity: after an owned wrapper marked its delayed decompile-project start, I temporarily made only my isolated cache's staging parent non-writable, cancelled the only assembly waiter, and called close_binary. The actual filesystem returned EACCES for removing the owned staging directory.

Observed sequence:

close_binary: cleanup_incomplete, with the correct recovery: {kind:"retry_cleanup", operation:"close_binary"}.
binary_session(detail:"summary"): open:false, cleanup_pending:true, but the group containing procedure_assembly still says target_required / “Call open_binary with a supported local target.”
Immediate open_binary: cleanup_incomplete.
Restore the original directory permissions, retry close_binary: success. Status then reports no pending cleanup. Client/transport shutdown was awaited.

The same real-provider workflow without the permission refusal closed successfully in two controls (one with cancellation), so this does not establish a natural failure frequency or reproduce the original ownership-visibility cause. These are six completed MCP calls plus the cancelled assembly request in the failing sequence; not unit-test passes, Linux evidence or an engine-wide qualification.

I read the actual production changes of #8329: they bind the close-error retry to its retaining owner, but do not carry that owner-specific prerequisite into status availability. I am preparing a focused shared-owner projection fix for this issue. It must preserve external-mutation and other owners' different recovery, and must not infer that every cleanup_pending state is retried by close_binary. No lifecycle, timeout, retry, process termination or cleanup-owner guard will be weakened.

Delivery update — 2026-11-02

Submitted Draft PR #8628 after normal fork commit/push, head 4ed87ffc3d68e119e468314b2e8de5312b2859b1 (base 8250bf232). The fix projects only the existing retaining close error's bound retry into optional session metadata and target-dependent guidance; it does not change cleanup, cancellation or retry execution. Final local evidence: 166 distinct passing tests, full check/docs/discovery/package, and installed real-Kuna MCP recovery with restored permissions and awaited cleanup. The last two files' 50 passes replace overlapping results; other test/product inputs are unchanged. New-head upstream CI is still pending and complete Codex review is not established. Windows/Linux and other providers are not qualified by this experiment. This update follows implementation; the original measured report above preceded it.

@xu91102 commented on GitHub (Nov 2, 2026): I reproduced the status-guidance gap on current main `8250bf2320ea57aab4e664db4b4d44b8abd2004e`, with the actual compiled stdio MCP server, official unmodified Kuna 1.988/macOS arm64, and an owned clang-built Mach-O. The target was never executed and its SHA-256 stayed unchanged. This is a **different controlled cleanup condition** from the report's withheld process identity: after an owned wrapper marked its delayed `decompile-project` start, I temporarily made only my isolated cache's `staging` parent non-writable, cancelled the only assembly waiter, and called `close_binary`. The actual filesystem returned EACCES for removing the owned staging directory. Observed sequence: 1. `close_binary`: `cleanup_incomplete`, with the correct `recovery: {kind:"retry_cleanup", operation:"close_binary"}`. 2. `binary_session(detail:"summary")`: `open:false`, `cleanup_pending:true`, but the group containing `procedure_assembly` still says `target_required` / “Call open_binary with a supported local target.” 3. Immediate `open_binary`: `cleanup_incomplete`. 4. Restore the original directory permissions, retry `close_binary`: success. Status then reports no pending cleanup. Client/transport shutdown was awaited. The same real-provider workflow without the permission refusal closed successfully in two controls (one with cancellation), so this does not establish a natural failure frequency or reproduce the original ownership-visibility cause. These are six completed MCP calls plus the cancelled assembly request in the failing sequence; not unit-test passes, Linux evidence or an engine-wide qualification. I read the actual production changes of #8329: they bind the close-error retry to its retaining owner, but do not carry that owner-specific prerequisite into status availability. I am preparing a focused shared-owner projection fix for this issue. It must preserve external-mutation and other owners' different recovery, and must not infer that every `cleanup_pending` state is retried by `close_binary`. No lifecycle, timeout, retry, process termination or cleanup-owner guard will be weakened. ### Delivery update — 2026-11-02 Submitted Draft PR #8628 after normal fork commit/push, head `4ed87ffc3d68e119e468314b2e8de5312b2859b1` (base `8250bf232`). The fix projects only the existing retaining close error's bound retry into optional session metadata and target-dependent guidance; it does not change cleanup, cancellation or retry execution. Final local evidence: 166 distinct passing tests, full check/docs/discovery/package, and installed real-Kuna MCP recovery with restored permissions and awaited cleanup. The last two files' 50 passes replace overlapping results; other test/product inputs are unchanged. New-head upstream CI is still pending and complete Codex review is not established. Windows/Linux and other providers are not qualified by this experiment. This update follows implementation; the original measured report above preceded it.

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

No description provided.

Rows
Columns