[GH-ISSUE #4835] [Bug] Android cleanup retry loses the typed operation failure and retains stale resource attribution #3005

New issue

Closed

opened 2026-10-31 00:34:43 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

Before submitting

Searched open and closed issue titles for JADX/Android cleanup; #1441 concerns the test fixture's teardown reason, a different behavior. Related: #3517.
Removed credentials and private target data.

Area

Native analysis or decompilation

Observed behavior

Source-derived finding at 63c65a22430a4bbc0c1807a0298edb867775001f. If a JADX operation fails and retiring its session or workspace also fails, cleanup() returns a new cleanup-only ProviderCleanupError. The primary survives only in a cause or diagnostic snapshot. It has no canonical cleanupPrimary relationship. After cleanup retry succeeds, #retire() clears the cleanup flag on the reported wrapper, but projection cannot recover the original typed operation failure. Resource attribution is also a fixed snapshot, even if the session is later closed while workspace cleanup remains pending.

Source: cleanup and retry owner.

Reproduction

No real JVM cleanup failure reproduced. This is a source review of the error/ownership path. Existing child-process fixtures exercise injected cleanup failures; the proposed regression extends them to retain the original reported error across session cleanup, a later workspace-close failure, and successful retry.

Expected behavior

Compose the primary using the existing analysisErrorWithCleanupFailure contract, bind resource attribution to the retained acquisition record, and restore the original error projection after cleanup recovers. Retain the workspace until process cleanup is proven complete.

Impact and scope

Typed input, cancellation, timeout, or resource failures can lose their classification/remediation after cleanup retry. Actual frequency is unknown. This is directly relevant to preserving the new memory failure in #3517. No real-provider or Windows verification is claimed.

REA version

Source 63c65a22430a4bbc0c1807a0298edb867775001f (6.5.0).

Runtime and platform

Source review; candidate controlled tests on macOS arm64, Node 24.18.0. NOT_ENOUGH_INFO for a real JVM cleanup-failure environment.

Target and artifact context

Authored protocol fixture; no private APK or target execution.

Interface

Other: shared Android provider, consumed by CLI/MCP.

Earliest failure stage

Cleanup, cancellation, or lifecycle

Originally created by @morluto on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4835 ### Before submitting - [x] Searched open and closed issue titles for JADX/Android cleanup; #1441 concerns the test fixture's teardown reason, a different behavior. Related: #3517. - [x] Removed credentials and private target data. ### Area Native analysis or decompilation ### Observed behavior **Source-derived finding at `63c65a22430a4bbc0c1807a0298edb867775001f`.** If a JADX operation fails and retiring its session or workspace also fails, `cleanup()` returns a new cleanup-only `ProviderCleanupError`. The primary survives only in a cause or diagnostic snapshot. It has no canonical `cleanupPrimary` relationship. After cleanup retry succeeds, `#retire()` clears the cleanup flag on the reported wrapper, but projection cannot recover the original typed operation failure. Resource attribution is also a fixed snapshot, even if the session is later closed while workspace cleanup remains pending. Source: [cleanup and retry owner](https://github.com/morluto/rea/blob/63c65a22430a4bbc0c1807a0298edb867775001f/src/android/JadxProvider.ts#L219). ### Reproduction No real JVM cleanup failure reproduced. This is a source review of the error/ownership path. Existing child-process fixtures exercise injected cleanup failures; the proposed regression extends them to retain the original reported error across session cleanup, a later workspace-close failure, and successful retry. ### Expected behavior Compose the primary using the existing `analysisErrorWithCleanupFailure` contract, bind resource attribution to the retained acquisition record, and restore the original error projection after cleanup recovers. Retain the workspace until process cleanup is proven complete. ### Impact and scope Typed input, cancellation, timeout, or resource failures can lose their classification/remediation after cleanup retry. Actual frequency is unknown. This is directly relevant to preserving the new memory failure in #3517. No real-provider or Windows verification is claimed. ### REA version Source `63c65a22430a4bbc0c1807a0298edb867775001f` (6.5.0). ### Runtime and platform Source review; candidate controlled tests on macOS arm64, Node 24.18.0. NOT_ENOUGH_INFO for a real JVM cleanup-failure environment. ### Target and artifact context Authored protocol fixture; no private APK or target execution. ### Interface Other: shared Android provider, consumed by CLI/MCP. ### Earliest failure stage Cleanup, cancellation, or lifecycle

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

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

Fixed on main in 9fa6d2b25; typed memory recovery coverage follows in 3fa972af7.

Cleanup now uses the canonical primary-error composition and binds current resources to the retained acquisition record. Session, descriptor and workspace ownership no longer depend on stale diagnostic snapshots or duplicate failed-handle records. Retry resolves previously reported errors and restores the primary projection.

Controlled regression: baseline 63c65a224 retained stale process/workspace IDs after recovery; the isolated three-file cleanup change passes the strengthened regression. Candidate coverage also exercises a typed load-memory failure, failed session cleanup, subsequent workspace-close failure, late shutdown cancellation, shrinking live resources, and final recovery of the original memory error/remediation. The final three affected process suites passed (57 tests). Static checks and commit/push hooks passed.

No real JVM cleanup failure or Windows run is claimed. These are production-boundary fixtures with deliberately injected cleanup outcomes. Related #3517 is fixed without requiring memory-pressure stress.

@morluto commented on GitHub (Oct 17, 2026): Fixed on main in 9fa6d2b25; typed memory recovery coverage follows in 3fa972af7. Cleanup now uses the canonical primary-error composition and binds current resources to the retained acquisition record. Session, descriptor and workspace ownership no longer depend on stale diagnostic snapshots or duplicate failed-handle records. Retry resolves previously reported errors and restores the primary projection. Controlled regression: baseline 63c65a224 retained stale process/workspace IDs after recovery; the isolated three-file cleanup change passes the strengthened regression. Candidate coverage also exercises a typed load-memory failure, failed session cleanup, subsequent workspace-close failure, late shutdown cancellation, shrinking live resources, and final recovery of the original memory error/remediation. The final three affected process suites passed (57 tests). Static checks and commit/push hooks passed. No real JVM cleanup failure or Windows run is claimed. These are production-boundary fixtures with deliberately injected cleanup outcomes. Related #3517 is fixed without requiring memory-pressure stress.

bsakaguchi referenced this issue

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

[GH-ISSUE #5396] [Bug] Duplicate record_unknown calls are reported as retryable revision conflicts #3266

bsakaguchi referenced this issue

2026-10-31 00:43:31 +00:00

[GH-ISSUE #6106] [Bug] Residual-unknown input validation is reported as changed Evidence state #3738

bsakaguchi referenced this issue

2026-11-01 21:10:57 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471