[GH-ISSUE #4808] [Bug] Apktool command finalization loses cleanup recovery and cancellation ownership #2499

New issue

Closed

opened 2026-10-17 21:05:46 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-17 21:05:46 +00:00

Owner

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

Area

Cleanup, cancellation, or lifecycle / Apktool version discovery and owned commands.

Observed behavior

Source-derived at 376eeca770: inspectApktoolClient charges ownership-helper preparation to its fixed 20-second version-command deadline. It projects cancellation with the wrapper as its cause, and can let a later aborted signal replace a physical failure. Helper preparation cleanup is not retained. For command cleanup, the provider retains a supervisor, but original errors have no release binding and another availability/execute operation can launch while teardown is unresolved.

Reproduction / evidence

Source inspection: src/apktool/ApktoolConfiguration.ts version execution/catch; src/apktool/ApktoolProvider.ts #retainProbeOwner, admission and #drainAndClean. The latter retries supervisors on close, then discards them; prior projected errors stay incomplete. No natural OS cleanup denial or actual cold compiler reproduction was performed. Controlled ownership/admission tests are proposed.

Expected behavior

Keep independently bounded Darwin compilation outside the version-command deadline while keeping Linux process-table preparation bounded. Preserve exact caller cancellation reason and physical primary failures. Retain exact helper/process cleanup capabilities, bind original and aggregate error status, and block replacement acquisition until cleanup recovers.

Impact / scope

Potential false version unavailability on cold macOS hosts, repeated acquisition with unresolved teardown, missing helper cleanup and stale error resource status. Runtime frequency: NOT_ENOUGH_INFO. Read-only launcher version probing; no new execution authority requested.

Version / platform / interface

Source 376eeca77, REA 6.5.0; source audit on macOS arm64; shared provider behind CLI/MCP/doctor. Real Apktool failing host scenario: NOT_ENOUGH_INFO.

#4793 fixed this preparation boundary for the Ghidra Java prerequisite. Existing #4638 concerns shared command cancellation provenance; this report concerns the Apktool consumer's interpretation/ownership after that boundary. Source descriptor/workspace finalization is a distinct next audit area, not claimed fixed by this command owner report.

Originally created by @morluto on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4808 ### Area Cleanup, cancellation, or lifecycle / Apktool version discovery and owned commands. ### Observed behavior Source-derived at 376eeca770820b31f7f8d4c5fcc397315621643e: `inspectApktoolClient` charges ownership-helper preparation to its fixed 20-second version-command deadline. It projects cancellation with the wrapper as its cause, and can let a later aborted signal replace a physical failure. Helper preparation cleanup is not retained. For command cleanup, the provider retains a supervisor, but original errors have no release binding and another availability/execute operation can launch while teardown is unresolved. ### Reproduction / evidence Source inspection: `src/apktool/ApktoolConfiguration.ts` version execution/catch; `src/apktool/ApktoolProvider.ts` `#retainProbeOwner`, admission and `#drainAndClean`. The latter retries supervisors on close, then discards them; prior projected errors stay incomplete. No natural OS cleanup denial or actual cold compiler reproduction was performed. Controlled ownership/admission tests are proposed. ### Expected behavior Keep independently bounded Darwin compilation outside the version-command deadline while keeping Linux process-table preparation bounded. Preserve exact caller cancellation reason and physical primary failures. Retain exact helper/process cleanup capabilities, bind original and aggregate error status, and block replacement acquisition until cleanup recovers. ### Impact / scope Potential false version unavailability on cold macOS hosts, repeated acquisition with unresolved teardown, missing helper cleanup and stale error resource status. Runtime frequency: NOT_ENOUGH_INFO. Read-only launcher version probing; no new execution authority requested. ### Version / platform / interface Source 376eeca77, REA 6.5.0; source audit on macOS arm64; shared provider behind CLI/MCP/doctor. Real Apktool failing host scenario: NOT_ENOUGH_INFO. ### Related findings #4793 fixed this preparation boundary for the Ghidra Java prerequisite. Existing #4638 concerns shared command cancellation provenance; this report concerns the Apktool consumer's interpretation/ownership after that boundary. Source descriptor/workspace finalization is a distinct next audit area, not claimed fixed by this command owner report.

bsakaguchi

2026-10-17 21:05:46 +00:00

closed this issue
added the
triage

bug
labels

bsakaguchi commented

2026-10-17 21:05:48 +00:00

Author

Owner

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

Fixed in 11bcf44252cc095a77a4c6d10290df48f491fdde on main.

One command scope retains exact process/helper cleanup capabilities. Unresolved cleanup blocks replacement acquisition, retains the associated workspace, and remains visible when no recovery capability exists. Successful retries update original and retry errors; released peers are not stopped twice.
Version output is interpreted once at completion before final cleanup. Physical failures survive later cancellation, opaque abort reasons and compiler output survive recovery, and decode prerequisite failures retain the consuming operation.
Darwin preparation precedes the version command's 20-second deadline.

Validation: 106 focused tests across 11 files, followed by 44 source checks on the final changes; build, typecheck/lint, documentation, test discovery (1540 files exactly once), and commit/push hooks passed. Eight new controls fail on clean baseline 376eeca77 for the expected defects. Two read-only reviews completed. Controlled failure seams cover denial/retry, missing recovery capability, mixed outcomes, final-cleanup cancellation, and late helper handoff during shutdown.

18 tiny completed before/after tasks used an authored Node launcher: actual CLI, actual stdio MCP, and three direct provider probes. Full replies were byte-identical. Repeated-process medians (baseline → fixed):

Task	Elapsed seconds	CPU seconds	Sampled family RSS MiB	Reply token estimate
CLI	0.815 → 0.814	1.073 → 1.077	495.8 → 495.4	194 → 194
stdio MCP	0.958 → 0.960	1.225 → 1.227	612.9 → 611.8	428 → 428
Three provider probes	0.692 → 0.690	0.716 → 0.722	255.2 → 259.5	275 → 275

No speedup claim. Two alternating repeats plus separate first processes; caches were not flushed. CPU uses wait4; RSS samples can miss short-lived/reparented processes. Tokens are cl100k reply estimates, excluding discovery, requests and agent continuations. Actual Apktool/JVM, native Windows, cold helper compilation and natural OS cleanup denial were not verified. Heavy stress/profiling remained stopped.

Context7's Node 24 process documentation supports retaining process-family supervision: signaling a launcher does not establish child cleanup. DeepWiki was used to locate upstream launcher behavior, without adopting its unsupported general cleanup guarantee.

Separate audit work remains for raw descriptors and workspace cleanup/finalization; this commit does not establish those resources are fully repaired.

@morluto commented on GitHub (Oct 17, 2026): Fixed in `11bcf44252cc095a77a4c6d10290df48f491fdde` on main. - One command scope retains exact process/helper cleanup capabilities. Unresolved cleanup blocks replacement acquisition, retains the associated workspace, and remains visible when no recovery capability exists. Successful retries update original and retry errors; released peers are not stopped twice. - Version output is interpreted once at completion before final cleanup. Physical failures survive later cancellation, opaque abort reasons and compiler output survive recovery, and decode prerequisite failures retain the consuming operation. - Darwin preparation precedes the version command's 20-second deadline. Validation: 106 focused tests across 11 files, followed by 44 source checks on the final changes; build, typecheck/lint, documentation, test discovery (1540 files exactly once), and commit/push hooks passed. Eight new controls fail on clean baseline `376eeca77` for the expected defects. Two read-only reviews completed. Controlled failure seams cover denial/retry, missing recovery capability, mixed outcomes, final-cleanup cancellation, and late helper handoff during shutdown. 18 tiny completed before/after tasks used an authored Node launcher: actual CLI, actual stdio MCP, and three direct provider probes. Full replies were byte-identical. Repeated-process medians (baseline → fixed): | Task | Elapsed seconds | CPU seconds | Sampled family RSS MiB | Reply token estimate | | --- | --- | --- | --- | --- | | CLI | 0.815 → 0.814 | 1.073 → 1.077 | 495.8 → 495.4 | 194 → 194 | | stdio MCP | 0.958 → 0.960 | 1.225 → 1.227 | 612.9 → 611.8 | 428 → 428 | | Three provider probes | 0.692 → 0.690 | 0.716 → 0.722 | 255.2 → 259.5 | 275 → 275 | No speedup claim. Two alternating repeats plus separate first processes; caches were not flushed. CPU uses wait4; RSS samples can miss short-lived/reparented processes. Tokens are cl100k reply estimates, excluding discovery, requests and agent continuations. Actual Apktool/JVM, native Windows, cold helper compilation and natural OS cleanup denial were not verified. Heavy stress/profiling remained stopped. Context7's [Node 24 process documentation](https://nodejs.org/docs/latest-v24.x/api/child_process.html#subprocesskillsignal) supports retaining process-family supervision: signaling a launcher does not establish child cleanup. DeepWiki was used to locate upstream launcher behavior, without adopting its unsupported general cleanup guarantee. Separate audit work remains for raw descriptors and workspace cleanup/finalization; this commit does not establish those resources are fully repaired.

bsakaguchi referenced this issue

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

[PR #2499] [MERGED] fix(hopper): stop Linux demo children when the REA owner exits #5276

bsakaguchi referenced this issue

2026-11-03 21:43:16 +00:00

[GH-ISSUE #2156] docs: correct documentation drift and simplify English guides #708