[GH-ISSUE #4702] [Bug] Kuna command cleanup retry leaves original ownership unresolved #2454

Closed
opened 2026-10-17 21:04:53 +00:00 by bsakaguchi · 4 comments
Owner

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

Before submitting

  • Searched open and closed Kuna cleanup reports. #4693 fixes projections following a resolved producer; this report concerns the command producer never resolving its original cleanup error.
  • No credentials or sensitive target data included.

Area

Native analysis or decompilation

Observed behavior

A controlled fake-Kuna boundary check reached successful session close after an initially unproven command stop was retried, but the original caller error still had cleanupIncomplete=true. Source inspection shows KunaTargetCommands.close removes its retained command and releases admission after supervisor stop succeeds, without resolving that command's original error. The error covers both process resources and its private workspace, so process stop alone is also insufficient to resolve it.

Reproduction

Production-boundary check on 988494abd plus local cancellation-reason mapping changes for #4700 (not a clean released-build or public CLI reproduction):

  1. Start a tiny fake Kuna strings command through the real owned process launcher.
  2. Cancel the last waiter. The controlled launcher actually stops the fake process but reports unproven cleanup until explicitly released.
  3. Observe incomplete cleanup, then let the launcher prove stop and retry client.close.
  4. close returns ok while the original error still reports cleanupIncomplete=true; assertion expected false, received true.

The current local repair passes this check and an added conjunctive control: after process proof, refuse the exact workspace owner's close; the original error must remain incomplete with only that workspace attributed. Retry the workspace close and require original and close-result errors to resolve.

Expected behavior

The exact process and workspace owners jointly control the error's live cleanup state. Preserve unresolved ownership and retry capability after either failure. Caller projections and older aggregate close errors must follow those exact owners; do not clear cleanup solely because a later close result is successful.

Impact and scope

Confirmed with a tiny fake executable and real process supervision on Darwin. Cleanup-proof loss is injected, not an actual failure to kill the child. Real Kuna, Windows and public CLI/MCP delivery are unverified. Affected consumers may keep reporting stale ownership after cleanup succeeded.

REA version

Source 988494abd; controlled check included local #4700 reason-mapping changes. No version regression range established.

Runtime and platform

Darwin arm64 / Node 24.18.0. Fake Kuna; no actual target execution.

Target and artifact context

Tiny generated program fixture; private command workspace and real fake-process group.

Interface

Other — shared provider client boundary.

Earliest failure stage

Cleanup, cancellation, or lifecycle.

Relevant output or evidence

  • Observed assertion after successful close: cleanupIncomplete expected false, received true.
  • Retained command admission stores the original error/supervisor.
  • Command close removes the retained record and releases the run slot without linking the original error to confirmed resource release.
  • Command failure construction attributes both process resources and workspace.

Analysis or suspected cause

No exact conjunctive cleanup binding between the original error and process/workspace owners. Existing AnalysisCleanupLeaseGroup provides this representation. Related #4700 cancellation handling needs this corrected producer state rather than another downstream snapshot repair.

Originally created by @morluto on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4702 ### Before submitting - [x] Searched open and closed Kuna cleanup reports. #4693 fixes projections following a resolved producer; this report concerns the command producer never resolving its original cleanup error. - [x] No credentials or sensitive target data included. ### Area Native analysis or decompilation ### Observed behavior A controlled fake-Kuna boundary check reached successful session close after an initially unproven command stop was retried, but the original caller error still had cleanupIncomplete=true. Source inspection shows KunaTargetCommands.close removes its retained command and releases admission after supervisor stop succeeds, without resolving that command's original error. The error covers both process resources and its private workspace, so process stop alone is also insufficient to resolve it. ### Reproduction Production-boundary check on 988494abd plus local cancellation-reason mapping changes for #4700 (not a clean released-build or public CLI reproduction): 1. Start a tiny fake Kuna strings command through the real owned process launcher. 2. Cancel the last waiter. The controlled launcher actually stops the fake process but reports unproven cleanup until explicitly released. 3. Observe incomplete cleanup, then let the launcher prove stop and retry client.close. 4. close returns ok while the original error still reports cleanupIncomplete=true; assertion expected false, received true. The current local repair passes this check and an added conjunctive control: after process proof, refuse the exact workspace owner's close; the original error must remain incomplete with only that workspace attributed. Retry the workspace close and require original and close-result errors to resolve. ### Expected behavior The exact process and workspace owners jointly control the error's live cleanup state. Preserve unresolved ownership and retry capability after either failure. Caller projections and older aggregate close errors must follow those exact owners; do not clear cleanup solely because a later close result is successful. ### Impact and scope Confirmed with a tiny fake executable and real process supervision on Darwin. Cleanup-proof loss is injected, not an actual failure to kill the child. Real Kuna, Windows and public CLI/MCP delivery are unverified. Affected consumers may keep reporting stale ownership after cleanup succeeded. ### REA version Source 988494abd; controlled check included local #4700 reason-mapping changes. No version regression range established. ### Runtime and platform Darwin arm64 / Node 24.18.0. Fake Kuna; no actual target execution. ### Target and artifact context Tiny generated program fixture; private command workspace and real fake-process group. ### Interface Other — shared provider client boundary. ### Earliest failure stage Cleanup, cancellation, or lifecycle. ### Relevant output or evidence - Observed assertion after successful close: cleanupIncomplete expected false, received true. - [Retained command admission](https://github.com/morluto/rea/blob/988494abd/src/kuna/KunaTargetCommands.ts#L130) stores the original error/supervisor. - [Command close](https://github.com/morluto/rea/blob/988494abd/src/kuna/KunaTargetCommands.ts#L176) removes the retained record and releases the run slot without linking the original error to confirmed resource release. - [Command failure construction](https://github.com/morluto/rea/blob/988494abd/src/kuna/KunaCommand.ts#L299) attributes both process resources and workspace. ### Analysis or suspected cause No exact conjunctive cleanup binding between the original error and process/workspace owners. Existing AnalysisCleanupLeaseGroup provides this representation. Related #4700 cancellation handling needs this corrected producer state rather than another downstream snapshot repair.
Author
Owner

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

Fixed in 592793717, pushed to main, with #4700.

The retained command's original error is now bound to a conjunctive group of exact process and workspace cleanup leases. Process proof releases native admission and removes only the process attribution; the workspace remains owned until its exact close succeeds. Root failures retain that same lease for retry. Command/session close aggregates follow the leaf errors, and concurrent command close calls share one attempt. Command failures also retain their typed primary outcome and captured output through cleanup failure.

Controlled validation uses a tiny fake strings process through real supervision with injected unproven cleanup. After proving stop, an injected failure on the actual workspace owner keeps the original error incomplete and attributed only to the workspace. Retrying that owner resolves the original caller and older close results. Concurrent close calls perform one root-close attempt. Final native cancellation/cleanup controls passed 6/6; the final overlapping focused run passed 15, with earlier 41-check and nine selected sharing controls also passing. Build/typecheck/lint/docs/hooks passed. Bounded combined-task costs and public CLI cancellation scope are recorded on #4700.

Cleanup-proof loss and workspace refusal were controlled injections; this is not a real failure to kill Kuna. Real Kuna, Windows and public CLI/MCP delivery of the cleanup fault remain unverified. Pre-command workspace allocation/rollback diagnostics and other descriptor aggregate bindings remain separate audit candidates; the fix covers retained native command and its exact workspace ownership.

<!-- gh-comment-id:6230786260 --> @morluto commented on GitHub (Oct 17, 2026): Fixed in 592793717, pushed to main, with #4700. The retained command's original error is now bound to a conjunctive group of exact process and workspace cleanup leases. Process proof releases native admission and removes only the process attribution; the workspace remains owned until its exact close succeeds. Root failures retain that same lease for retry. Command/session close aggregates follow the leaf errors, and concurrent command close calls share one attempt. Command failures also retain their typed primary outcome and captured output through cleanup failure. Controlled validation uses a tiny fake strings process through real supervision with injected unproven cleanup. After proving stop, an injected failure on the actual workspace owner keeps the original error incomplete and attributed only to the workspace. Retrying that owner resolves the original caller and older close results. Concurrent close calls perform one root-close attempt. Final native cancellation/cleanup controls passed 6/6; the final overlapping focused run passed 15, with earlier 41-check and nine selected sharing controls also passing. Build/typecheck/lint/docs/hooks passed. Bounded combined-task costs and public CLI cancellation scope are recorded on #4700. Cleanup-proof loss and workspace refusal were controlled injections; this is not a real failure to kill Kuna. Real Kuna, Windows and public CLI/MCP delivery of the cleanup fault remain unverified. Pre-command workspace allocation/rollback diagnostics and other descriptor aggregate bindings remain separate audit candidates; the fix covers retained native command and its exact workspace ownership.
Author
Owner

@XinwangTao commented on GitHub (Oct 17, 2026):

Agreed — binding the original error to a conjunctive group of process and workspace leases is much clearer than the old all-or-nothing flag, and making concurrent close calls share one attempt avoids the retry stampede. Two follow-ups worth considering: (1) once the two lease types exist, the single cleanupIncomplete boolean could be split or annotated per lease so callers can see exactly which lease is still held (process attribution vs workspace root); (2) document the retry contract for the shared attempt — e.g. whether a second close arriving mid-retry observes the in-flight attempt or is coalesced, since that affects supervisor-stop idempotency.

<!-- gh-comment-id:6231760739 --> @XinwangTao commented on GitHub (Oct 17, 2026): Agreed — binding the original error to a conjunctive group of process and workspace leases is much clearer than the old all-or-nothing flag, and making concurrent close calls share one attempt avoids the retry stampede. Two follow-ups worth considering: (1) once the two lease types exist, the single `cleanupIncomplete` boolean could be split or annotated per lease so callers can see exactly which lease is still held (process attribution vs workspace root); (2) document the retry contract for the shared attempt — e.g. whether a second close arriving mid-retry observes the in-flight attempt or is coalesced, since that affects supervisor-stop idempotency.
Author
Owner

@skyzhao1223 commented on GitHub (Oct 18, 2026):

Verified on current main (7c458f04b) that this no longer reproduces.

964decd98 (fix(providers): preserve live cleanup ownership through retries) is the fix in src/kuna/KunaInstallation.ts, and tests/boundary/providers/kuna/kunaCommandLifetime.test.ts plus kunaInstallationCancellation.test.ts pass on that revision.

Included in the rea-agents-6.6.0 release. Verification only; no action requested.

<!-- gh-comment-id:6247507101 --> @skyzhao1223 commented on GitHub (Oct 18, 2026): Verified on current `main` (`7c458f04b`) that this no longer reproduces. `964decd98` (`fix(providers): preserve live cleanup ownership through retries`) is the fix in `src/kuna/KunaInstallation.ts`, and `tests/boundary/providers/kuna/kunaCommandLifetime.test.ts` plus `kunaInstallationCancellation.test.ts` pass on that revision. Included in the `rea-agents-6.6.0` release. Verification only; no action requested.
Author
Owner

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

Closing as fixed on main after reconciling this report with the landed owner/consumer changes.

  • 592793717: fix(kuna): preserve cancellation and cleanup ownership.

Evidence scope: this closure uses the landed source, regression coverage and validation already recorded in the linked commits/thread. No new local tests or native-provider reproduction were run during this backlog pass; previously documented platform and real-provider gaps still apply.

<!-- gh-comment-id:6255989959 --> @morluto commented on GitHub (Oct 18, 2026): <!-- rea-backlog-reconciliation-2026-10-19-4702 --> Closing as fixed on `main` after reconciling this report with the landed owner/consumer changes. - [592793717](https://github.com/morluto/rea/commit/5927937179476c66aa8621658faca42f9578b42a): fix(kuna): preserve cancellation and cleanup ownership. Evidence scope: this closure uses the landed source, regression coverage and validation already recorded in the linked commits/thread. No new local tests or native-provider reproduction were run during this backlog pass; previously documented platform and real-provider gaps still apply.
Sign in to join this conversation.
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#2454
No description provided.