morluto/rea

Fork 0

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

[GH-ISSUE #4704] [Bug] Kuna workspace rollback hides retained cleanup #2456

New issue

Closed

opened 2026-10-17 21:04:56 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-17 21:04:56 +00:00

Owner

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

Before submitting

Searched open and closed issues for Kuna workspace rollback. #4702 concerns cleanup of an admitted native command; this finding occurs before command admission.
No credentials or sensitive target data included.

Area

Native analysis or decompilation

Observed behavior

Two controlled production-boundary checks confirm that failed workspace rollback is hidden from the caller. With a changed or missing selected target, KunaTargetCommands.prepare returns an error with cleanupIncomplete=false even though the exact created workspace owner's close was refused and that root remains retained for retry.

Reproduction

Source 592793717 on Darwin arm64 / Node 24.18.0, tiny generated target and fake Kuna used only for initial profile resolution:

Resolve the fixture profile, then either change the selected target bytes or remove the target.
Capture the actual PrivateRuntimeRoot owner allocated by prepare; inject a close refusal on that exact object.
Call commands.prepare. Both cases fail the assertion cleanupIncomplete=true (received false).
Restore that owner's close and close the command owner; the controlled workspace is removed.

Two cases, each observed once before the fix. No real Kuna analysis, target execution, public CLI or MCP fault reproduction. The source also clears the failed workspace promise and permits another allocation while retained roots remain; the baseline checks stop at the missing cleanup marker, so replacement is source-derived rather than a separate baseline runtime measurement.

Expected behavior

Preserve the original changed-target/read failure and attach the exact rollback cleanup dependency. Retain the failed root and block replacement while its cleanup remains unresolved. Close must join active setup/rollback and retry the same owner. Successful cleanup should update the originating error and older close reports, restoring the typed primary classification.

Impact and scope

Observed diagnostic mismatch at the command-owner boundary; retained target-copy directories can be omitted from the request's cleanup state. Repeated allocation while cleanup is retained follows from source. Real provider, Windows and external CLI/MCP delivery are unverified.

REA version

592793717 (package 6.5.0).

Runtime and platform

Darwin arm64 / Node 24.18.0; fake provider profile, no native analysis command.

Target and artifact context

Tiny generated file representing the selected target; private workspace and partial target copy. No sensitive target bytes.

Interface

Other — shared provider command-owner boundary.

Earliest failure stage

Cleanup, cancellation, or lifecycle.

Relevant output or evidence

Both changed/missing cases: cleanupIncomplete expected true, received false.

Workspace creation and rollback: digest/copy failures await #release, then return or wrap only the original failure.
Release: catches cleanup rejection and retains the root without attaching that failure to the caller outcome.
Failed attempt invalidation: all failed workspace promises are cleared.

Analysis or suspected cause

Cleanup ownership and request failure are separate representations. Bind the cleanup error to the existing exact root lease, compose it with the original typed failure, and retain the failed attempt while cleanup is incomplete. Proposed additional checks: cancellation during final rollback, clean rollback retry, and allocation failure before any root exists. No measurements beyond the checks above are claimed.

Originally created by @morluto on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4704 ### Before submitting - [x] Searched open and closed issues for Kuna workspace rollback. #4702 concerns cleanup of an admitted native command; this finding occurs before command admission. - [x] No credentials or sensitive target data included. ### Area Native analysis or decompilation ### Observed behavior Two controlled production-boundary checks confirm that failed workspace rollback is hidden from the caller. With a changed or missing selected target, KunaTargetCommands.prepare returns an error with cleanupIncomplete=false even though the exact created workspace owner's close was refused and that root remains retained for retry. ### Reproduction Source 592793717 on Darwin arm64 / Node 24.18.0, tiny generated target and fake Kuna used only for initial profile resolution: 1. Resolve the fixture profile, then either change the selected target bytes or remove the target. 2. Capture the actual PrivateRuntimeRoot owner allocated by prepare; inject a close refusal on that exact object. 3. Call commands.prepare. Both cases fail the assertion cleanupIncomplete=true (received false). 4. Restore that owner's close and close the command owner; the controlled workspace is removed. Two cases, each observed once before the fix. No real Kuna analysis, target execution, public CLI or MCP fault reproduction. The source also clears the failed workspace promise and permits another allocation while retained roots remain; the baseline checks stop at the missing cleanup marker, so replacement is source-derived rather than a separate baseline runtime measurement. ### Expected behavior Preserve the original changed-target/read failure and attach the exact rollback cleanup dependency. Retain the failed root and block replacement while its cleanup remains unresolved. Close must join active setup/rollback and retry the same owner. Successful cleanup should update the originating error and older close reports, restoring the typed primary classification. ### Impact and scope Observed diagnostic mismatch at the command-owner boundary; retained target-copy directories can be omitted from the request's cleanup state. Repeated allocation while cleanup is retained follows from source. Real provider, Windows and external CLI/MCP delivery are unverified. ### REA version 592793717 (package 6.5.0). ### Runtime and platform Darwin arm64 / Node 24.18.0; fake provider profile, no native analysis command. ### Target and artifact context Tiny generated file representing the selected target; private workspace and partial target copy. No sensitive target bytes. ### Interface Other — shared provider command-owner boundary. ### Earliest failure stage Cleanup, cancellation, or lifecycle. ### Relevant output or evidence Both changed/missing cases: cleanupIncomplete expected true, received false. - [Workspace creation and rollback](https://github.com/morluto/rea/blob/592793717/src/kuna/KunaTargetCommands.ts#L265): digest/copy failures await #release, then return or wrap only the original failure. - [Release](https://github.com/morluto/rea/blob/592793717/src/kuna/KunaTargetCommands.ts#L308): catches cleanup rejection and retains the root without attaching that failure to the caller outcome. - [Failed attempt invalidation](https://github.com/morluto/rea/blob/592793717/src/kuna/KunaTargetCommands.ts#L303): all failed workspace promises are cleared. ### Analysis or suspected cause Cleanup ownership and request failure are separate representations. Bind the cleanup error to the existing exact root lease, compose it with the original typed failure, and retain the failed attempt while cleanup is incomplete. Proposed additional checks: cancellation during final rollback, clean rollback retry, and allocation failure before any root exists. No measurements beyond the checks above are claimed.

bsakaguchi added the

triage

bug

labels

2026-10-17 21:04:56 +00:00

bsakaguchi commented

2026-10-17 21:04:59 +00:00

Author

Owner

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

Fixed in 264799b0f, pushed to main.

Workspace failure and rollback now share one outcome and the exact existing root lease. The original changed-target/read failure remains primary; rollback refusal adds a live cleanup dependency. The failed attempt stays cached while cleanup is unresolved, preventing replacement. Clean rollback permits retry. This removes the silent release wrapper and nested exception wrapping; unknown thrown values remain opaque causes rather than granting cleanup authority. Failed-attempt invalidation checks the exact promise identity.

Validation on Darwin arm64/Node 24.18:

The two original changed/missing-target controls failed before the fix and passed afterward.
Final focused selection: 34 checks across four files passed. Final overlapping workspace-only run: 10 passed. Coverage includes exact-owner refusal/retry, blocked allocation, cancellation and close during final rollback, preserved typed primary failure, clean rollback retry, allocation failure without an owner, foreign error/null causes without authority adoption, and caller operation/selected-path preservation.
Build, typecheck/lint, documentation checks (five README controls) and hooks passed. Main advanced with a test-only graph-context change; rebased cleanly, ran its three affected graph controls (14 others skipped), and the runtime fingerprint remained unchanged.

Bounded completed command-owner missing-target preparation plus clean rollback, same selected path/digest and byte-identical error projections: first-process baseline/candidate elapsed 0.098863/0.059739 s, CPU 0.069064/0.057141 s, sampled process-family RSS 69.0/60.5 MB. Two alternating warm repeats gave medians elapsed 0.058978/0.059188 s, CPU 0.058313/0.058815 s, sampled RSS 59.0/59.9 MB. Both replies were 173 raw cl100k tokens. No performance claim from these short tasks. CPU includes reaped children; sampled RSS can miss transients. True cold, whole-agent, CLI/MCP transport, injected rollback-fault and real-engine costs remain unmeasured. The exploratory comparison before final opaque-cause handling is retained separately.

Rollback refusal/allocation failure are controlled injections; no real Kuna analysis or target execution was performed for this finding. Real provider, Windows and public CLI/MCP delivery of the rollback fault remain unverified. Process-inspector preparation error contracts and remaining raw-exception/completion paths are separate audit candidates; this does not establish full lifecycle coverage.

@morluto commented on GitHub (Oct 17, 2026): Fixed in 264799b0f, pushed to main. Workspace failure and rollback now share one outcome and the exact existing root lease. The original changed-target/read failure remains primary; rollback refusal adds a live cleanup dependency. The failed attempt stays cached while cleanup is unresolved, preventing replacement. Clean rollback permits retry. This removes the silent release wrapper and nested exception wrapping; unknown thrown values remain opaque causes rather than granting cleanup authority. Failed-attempt invalidation checks the exact promise identity. Validation on Darwin arm64/Node 24.18: - The two original changed/missing-target controls failed before the fix and passed afterward. - Final focused selection: 34 checks across four files passed. Final overlapping workspace-only run: 10 passed. Coverage includes exact-owner refusal/retry, blocked allocation, cancellation and close during final rollback, preserved typed primary failure, clean rollback retry, allocation failure without an owner, foreign error/null causes without authority adoption, and caller operation/selected-path preservation. - Build, typecheck/lint, documentation checks (five README controls) and hooks passed. Main advanced with a test-only graph-context change; rebased cleanly, ran its three affected graph controls (14 others skipped), and the runtime fingerprint remained unchanged. Bounded completed **command-owner** missing-target preparation plus clean rollback, same selected path/digest and byte-identical error projections: first-process baseline/candidate elapsed 0.098863/0.059739 s, CPU 0.069064/0.057141 s, sampled process-family RSS 69.0/60.5 MB. Two alternating warm repeats gave medians elapsed 0.058978/0.059188 s, CPU 0.058313/0.058815 s, sampled RSS 59.0/59.9 MB. Both replies were 173 raw cl100k tokens. No performance claim from these short tasks. CPU includes reaped children; sampled RSS can miss transients. True cold, whole-agent, CLI/MCP transport, injected rollback-fault and real-engine costs remain unmeasured. The exploratory comparison before final opaque-cause handling is retained separately. Rollback refusal/allocation failure are controlled injections; no real Kuna analysis or target execution was performed for this finding. Real provider, Windows and public CLI/MCP delivery of the rollback fault remain unverified. Process-inspector preparation error contracts and remaining raw-exception/completion paths are separate audit candidates; this does not establish full lifecycle coverage.

bsakaguchi commented

2026-10-17 21:04:59 +00:00

Author

Owner

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

Good fix — making the rollback refusal a live cleanup dependency instead of a silently swallowed wrapper is the right call, and caching the failed attempt until cleanup resolves closes the replace-without-cleanup hole. One suggestion: consider surfacing the rollback refusal cause (the refused close error) in the user-facing diagnostic even when it stays secondary to the primary changed-target failure — a caller only sees the failed attempt cached, and distinguishing 'cleanup pending retry' from 'cleanup refused' would let tooling decide whether to retry or escalate. The exact promise identity check for invalidation is a nice touch.

@XinwangTao commented on GitHub (Oct 17, 2026): Good fix — making the rollback refusal a live cleanup dependency instead of a silently swallowed wrapper is the right call, and caching the failed attempt until cleanup resolves closes the replace-without-cleanup hole. One suggestion: consider surfacing the rollback refusal cause (the refused close error) in the user-facing diagnostic even when it stays secondary to the primary changed-target failure — a caller only sees the failed attempt cached, and distinguishing 'cleanup pending retry' from 'cleanup refused' would let tooling decide whether to retry or escalate. The exact promise identity check for invalidation is a nice touch.

bsakaguchi closed this issue

2026-10-31 00:34:08 +00:00

bsakaguchi commented

2026-10-31 00:34:09 +00:00

Author

Owner

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

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

npm run test:focused -- tests/boundary/providers/kuna/kunaWorkspaceRollback.test.ts passes (10 tests), including "retains a changed target's failed workspace rollback and blocks replacement until retry" and the missing-target variant.

Fixed by 264799b0f (fix(kuna): retain workspace rollback failures), in the rea-agents-6.6.0 release. Verification only; no action requested.

@skyzhao1223 commented on GitHub (Oct 18, 2026): Verified on current `main` (`7c458f04b`) that this no longer reproduces. `npm run test:focused -- tests/boundary/providers/kuna/kunaWorkspaceRollback.test.ts` passes (10 tests), including "retains a changed target's failed workspace rollback and blocks replacement until retry" and the missing-target variant. Fixed by `264799b0f` (`fix(kuna): retain workspace rollback failures`), in the `rea-agents-6.6.0` release. Verification only; no action requested.

bsakaguchi commented

2026-10-31 00:34:10 +00:00

Author

Owner

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

I would like to investigate this bug and add a regression test for the
retained KUNA workspace cleanup failure. Is anyone currently working on it?
If it is available, may I take it?

@rajverma04 commented on GitHub (Oct 18, 2026): I would like to investigate this bug and add a regression test for the retained KUNA workspace cleanup failure. Is anyone currently working on it? If it is available, may I take it?

bsakaguchi commented

2026-10-31 00:34:11 +00:00

Author

Owner

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

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

264799b0f: fix(kuna): retain workspace rollback failures.

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.

@morluto commented on GitHub (Oct 18, 2026):  Closing as fixed on `main` after reconciling this report with the landed owner/consumer changes. - [264799b0f](https://github.com/morluto/rea/commit/264799b0ff501b2d2da36153fd3afbc063ab9ef4): fix(kuna): retain workspace rollback failures. 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.

bsakaguchi referenced this issue

2026-10-31 00:41:20 +00:00

[GH-ISSUE #5802] perf(rust): query selected dependency facts from retained Evidence #3513

bsakaguchi referenced this issue

2026-10-31 01:05:05 +00:00

[PR #2456] [MERGED] feat(native): read embedded cargo-auditable Rust dependency lists #5242