[GH-ISSUE #4844] [Bug] JADX startup errors freeze diagnostics before owned output finalization #3011

New issue

Closed

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

bsakaguchi commented

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

Owner

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

Before submitting

Searched open/closed JADX diagnostics and shared-supervisor reports. Related #3517, PR #3573 and #4840; the typed load failure and shared producer corrections do not fix this consumer snapshot.
Removed credentials and private target data.

Area

Provider or capability discovery

Observed behavior

Source-derived finding at 7016951394. In JadxProvider.#execute, the catch constructs executionError() before awaiting #retire(). For a failed initial handshake, executionError() immediately copies session.transport.diagnostics() into both the reason and captured output. Stderr arriving during owned cleanup/output finalization therefore cannot appear in the returned error, even with the shared supervisor correction in #4840. The generic startup text also directs every launcher failure toward JDK/compiler remediation without establishing that cause.

Source: Android failure projection and the catch/retirement boundary in the same file.

Reproduction

Source review only; NOT_ENOUGH_INFO for a controlled Android startup regression or a real JVM reproduction in this report. The separate shared-process control for #4840 proves exit-before-output-close and its correction, but does not prove Android's user-facing error is updated. PR #3573 separately reports early tiny-heap launcher cases; those were not rerun here.

Expected behavior

Freeze the primary failure at its owning observation boundary, finalize the owned process output, then present the same failure with final available diagnostics and explicit incompleteness. Do not resample later abort/deadline state to replace an earlier physical failure. Preserve typed errors, partial observations and cleanup retry ownership. Diagnose missing JDK modules at the existing prerequisite boundary; use actual retained launcher evidence for startup failure recovery.

Impact and scope

CLI/MCP share this adapter. Missing final stderr can hide the actual startup reason and suggest irrelevant repair. Frequency and native OS scope are unknown. No target execution or automatic JVM sizing is requested.

REA version

6.5.0 source 7016951394.

Runtime and platform

Source review on macOS arm64 / Node 24.18.0. NOT_ENOUGH_INFO for a real failing JVM environment.

Target and artifact context

No target artifact required for the source finding; proposed controls use an authored protocol launcher with held finalization and late stderr.

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/4844 ### Before submitting - [x] Searched open/closed JADX diagnostics and shared-supervisor reports. Related #3517, PR #3573 and #4840; the typed load failure and shared producer corrections do not fix this consumer snapshot. - [x] Removed credentials and private target data. ### Area Provider or capability discovery ### Observed behavior **Source-derived finding at 701695139490777ece7a3ccb8508b6215a11c0fe.** In `JadxProvider.#execute`, the catch constructs `executionError()` before awaiting `#retire()`. For a failed initial handshake, `executionError()` immediately copies `session.transport.diagnostics()` into both the reason and captured output. Stderr arriving during owned cleanup/output finalization therefore cannot appear in the returned error, even with the shared supervisor correction in #4840. The generic startup text also directs every launcher failure toward JDK/compiler remediation without establishing that cause. Source: [Android failure projection](https://github.com/morluto/rea/blob/701695139490777ece7a3ccb8508b6215a11c0fe/src/android/JadxProvider.ts#L75) and the catch/retirement boundary in the same file. ### Reproduction Source review only; NOT_ENOUGH_INFO for a controlled Android startup regression or a real JVM reproduction in this report. The separate shared-process control for #4840 proves exit-before-output-close and its correction, but does not prove Android's user-facing error is updated. PR #3573 separately reports early tiny-heap launcher cases; those were not rerun here. ### Expected behavior Freeze the primary failure at its owning observation boundary, finalize the owned process output, then present the same failure with final available diagnostics and explicit incompleteness. Do not resample later abort/deadline state to replace an earlier physical failure. Preserve typed errors, partial observations and cleanup retry ownership. Diagnose missing JDK modules at the existing prerequisite boundary; use actual retained launcher evidence for startup failure recovery. ### Impact and scope CLI/MCP share this adapter. Missing final stderr can hide the actual startup reason and suggest irrelevant repair. Frequency and native OS scope are unknown. No target execution or automatic JVM sizing is requested. ### REA version 6.5.0 source 701695139490777ece7a3ccb8508b6215a11c0fe. ### Runtime and platform Source review on macOS arm64 / Node 24.18.0. NOT_ENOUGH_INFO for a real failing JVM environment. ### Target and artifact context No target artifact required for the source finding; proposed controls use an authored protocol launcher with held finalization and late stderr. ### 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:49 +00:00

bsakaguchi commented

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

Author

Owner

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

Fixed on main in 3ad1032b11.

The transport now records its first physical/protocol/interruption failure before SDK teardown. The provider freezes that selection, joins owned retirement, then presents the retained stderr and output completeness. Later cancellation/deadlines cannot replace an observed startup failure. Cancellation checkpoints preserve opaque reasons, including foreign typed errors and cleanup owners. Startup advice refers to the observed diagnostics instead of always diagnosing a missing compiler.

Validation: 119 tests across eight focused files pass, including 25 new startup/lifecycle controls. Five selected controls fail on baseline 701695139 for missing terminal diagnostics, failure precedence, or foreign cancellation interpretation. Typecheck/lint, docs checks and test discovery pass. Two source reviewers report no remaining blockers in this scope.

Real-provider scope: nine CLI and nine MCP inspections pass on an authored five-class APK with pinned JADX 0.7.1/JDK 21. Six additional completed MCP workflows preserve equivalent normalized results. Two warm-repeat medians (baseline/candidate): elapsed 2.134/2.251 s; reaped-family CPU 3.296/3.471 s; sampled family RSS 842407936/853360640 bytes; cl100k reply estimate 9621.5/9614.5 tokens. This is a small normal-path cost check, not a speedup or whole-agent token claim. All six measured workspace roots are absent and no matching processes remain.

The failure controls use simulated process events with the real SDK/provider/MCP boundaries. Actual JVM startup failures/OOM, native Windows/Linux behavior and failure-path costs remain unverified. Heavy profiling/stress remain stopped. Context7 and DeepWiki informed SDK cancellation/close handling; the pinned installed SDK and regressions determine the implementation.

@morluto commented on GitHub (Oct 17, 2026): Fixed on main in 3ad1032b11edea2dcb054e78f951cc43159ae83d. The transport now records its first physical/protocol/interruption failure before SDK teardown. The provider freezes that selection, joins owned retirement, then presents the retained stderr and output completeness. Later cancellation/deadlines cannot replace an observed startup failure. Cancellation checkpoints preserve opaque reasons, including foreign typed errors and cleanup owners. Startup advice refers to the observed diagnostics instead of always diagnosing a missing compiler. Validation: 119 tests across eight focused files pass, including 25 new startup/lifecycle controls. Five selected controls fail on baseline 701695139 for missing terminal diagnostics, failure precedence, or foreign cancellation interpretation. Typecheck/lint, docs checks and test discovery pass. Two source reviewers report no remaining blockers in this scope. Real-provider scope: nine CLI and nine MCP inspections pass on an authored five-class APK with pinned JADX 0.7.1/JDK 21. Six additional completed MCP workflows preserve equivalent normalized results. Two warm-repeat medians (baseline/candidate): elapsed 2.134/2.251 s; reaped-family CPU 3.296/3.471 s; sampled family RSS 842407936/853360640 bytes; cl100k reply estimate 9621.5/9614.5 tokens. This is a small normal-path cost check, not a speedup or whole-agent token claim. All six measured workspace roots are absent and no matching processes remain. The failure controls use simulated process events with the real SDK/provider/MCP boundaries. Actual JVM startup failures/OOM, native Windows/Linux behavior and failure-path costs remain unverified. Heavy profiling/stress remain stopped. Context7 and DeepWiki informed SDK cancellation/close handling; the pinned installed SDK and regressions determine the implementation.

bsakaguchi referenced this issue

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

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425

bsakaguchi referenced this issue

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

[PR #3011] [CLOSED] fix(hopper): release a Spotlight not-found launch from the signed helper #5557