[GH-ISSUE #6532] [Bug] JEB drops completed analysis output when cancellation interrupts client metadata lookup #3922

New issue

Closed

opened 2026-10-31 00:45:16 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:45:16 +00:00

Owner

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

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

Source-only finding; runtime not run. On a fresh JEB provider, list_jeb_units first receives and validates the successful list_units payload, then awaits get_client_information. Cancelling during this second call returns typed cancellation without the already collected units or raw primary reply in partial_observation.

The same ordering occurs in open_jeb_project and decompile_jeb_item. These are variants of one retention failure, not separate reports. Cancellation itself is appropriate; the defect is dropping the observation received before cancellation.

Reproduction

Actually performed: traced the public service, production MCP connection, provider handlers and cancellation mapping at the revision below. No runtime fixture, REA command, JEB engine, test or build was run.

Proposed, unexecuted reproduction:

Start a loopback MCP fixture advertising list_units and get_client_information. Use a fresh REA server/provider without first calling inspect_jeb_client or readiness discovery.
Submit list_jeb_units with {"index":0,"count":2}.
Answer list_units with {"success":true,"units":[{"unit_path":"sample.dex","unit_type":"dex"}]}. Hold the subsequent get_client_information call pending.
Cancel the REA request while that metadata call is pending, then inspect the returned typed error. The source-derived result is cancellation without the successful primary payload in its partial observation.

NOT_ENOUGH_INFO: runtime reproduction frequency and behavior of a real JEB installation were not measured.

Expected behavior

Keep typed cancellation and the caller's abort reason, while retaining the successful primary reply as an explicitly partial observation with the requested operation and selectors. Metadata not obtained before cancellation must remain unavailable.

The lifecycle contract requires collected observations to survive typed cancellation. The shared completion path already retains Evidence for cancellation after Evidence assembly; the earlier JEB metadata await needs equivalent preservation.

Impact and scope

Source-derived scope: a fresh provider with no cached client metadata, after the primary operation succeeds and before metadata lookup completes. The caller loses a completed unit inventory, decompilation text, or project-open receipt. The normal metadata-success path is unaffected by this finding.

NOT_ENOUGH_INFO: real-provider frequency, downstream consequences and practical recovery of the original observation were not measured. Retrying analysis may collect a different observation. Calling inspect_jeb_client first in the same persistent provider appears to avoid the auxiliary lookup by source inspection, but was not executed as a workaround.

REA version

Source package 6.7.0, baseline commit 28a33cae8f8d4de8e11f7a266ff0d756432ab092.

Runtime and platform

Linux x64 source inspection only. No REA, Node.js or JEB runtime execution.

Target and artifact context

Proposed public fixture: one sample.dex project unit. No APK, DEX or JEB project was executed or opened.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

No runtime output is claimed. The source proves the following chain:

List handler: the primary payload is parsed into listed, then #engine is awaited before result creation or rawResult retention. Project open and decompilation use the same sequence.
Metadata acquisition: a fresh provider must await get_client_information.
Connection cancellation reaches the deadline mapper, which creates cancellation without a primary observation.
Provider error conversion copies only the error's existing partialObservation. The local primary payload is never attached. The shared service boundary returns that error before Evidence assembly.

Typed outcome or recovery expected

Restoration signal for the proposed fixture: cancellation still identifies list_jeb_units and preserves the abort reason, and partial_observation contains the previously received sample.dex unit and its successful primary reply or equivalent explicitly partial representation. Do not fabricate engine metadata. The metadata-success control should still return complete Evidence.

Analysis or suspected cause

Source-derived cause: the completed primary reply remains only in handler-local variables while a fallible metadata lookup runs. The outer catch can access only the thrown error, so it cannot recover those variables. The shared Evidence completion handler is too late to retain them.

Additional context

Related closed #4597 concerns incorrect operation attribution after an auxiliary metadata refusal. Its expected behavior explicitly excludes requiring successful Evidence after that probe fails. This report instead requires retention of collected facts under cancellation, without converting cancellation to success. Closed #3935 concerns later CLI cleanup failures. Open #4227 is the general lifecycle audit.

Open and closed issue searches covered JEB with get_client_information, metadata, discard, partial, and cancellation; no equivalent focused unresolved report was found. NOT_ENOUGH_INFO: introduction version and last known good version were not established.

Triage assessment

Impact level: P2
Assessment status: provisional
Impact basis: Source establishes loss of an already received primary analysis payload under a bounded cancellation sequence. Runtime occurrence and downstream consequences were not measured.
Workaround status: unverified
Workaround basis: Source suggests priming client metadata in the same persistent provider avoids this lookup, but no public runtime workaround or recovery of the discarded original observation was executed.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6532 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior Source-only finding; runtime not run. On a fresh JEB provider, `list_jeb_units` first receives and validates the successful `list_units` payload, then awaits `get_client_information`. Cancelling during this second call returns typed cancellation without the already collected units or raw primary reply in `partial_observation`. The same ordering occurs in `open_jeb_project` and `decompile_jeb_item`. These are variants of one retention failure, not separate reports. Cancellation itself is appropriate; the defect is dropping the observation received before cancellation. ### Reproduction Actually performed: traced the public service, production MCP connection, provider handlers and cancellation mapping at the revision below. No runtime fixture, REA command, JEB engine, test or build was run. Proposed, unexecuted reproduction: 1. Start a loopback MCP fixture advertising `list_units` and `get_client_information`. Use a fresh REA server/provider without first calling `inspect_jeb_client` or readiness discovery. 2. Submit `list_jeb_units` with `{"index":0,"count":2}`. 3. Answer `list_units` with `{"success":true,"units":[{"unit_path":"sample.dex","unit_type":"dex"}]}`. Hold the subsequent `get_client_information` call pending. 4. Cancel the REA request while that metadata call is pending, then inspect the returned typed error. The source-derived result is cancellation without the successful primary payload in its partial observation. NOT_ENOUGH_INFO: runtime reproduction frequency and behavior of a real JEB installation were not measured. ### Expected behavior Keep typed cancellation and the caller's abort reason, while retaining the successful primary reply as an explicitly partial observation with the requested operation and selectors. Metadata not obtained before cancellation must remain unavailable. The [lifecycle contract](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/docs/tool-design.md#L103-L109) requires collected observations to survive typed cancellation. The [shared completion path](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/src/application/ProviderOperationExecution.ts#L86-L99) already retains Evidence for cancellation after Evidence assembly; the earlier JEB metadata await needs equivalent preservation. ### Impact and scope Source-derived scope: a fresh provider with no cached client metadata, after the primary operation succeeds and before metadata lookup completes. The caller loses a completed unit inventory, decompilation text, or project-open receipt. The normal metadata-success path is unaffected by this finding. NOT_ENOUGH_INFO: real-provider frequency, downstream consequences and practical recovery of the original observation were not measured. Retrying analysis may collect a different observation. Calling `inspect_jeb_client` first in the same persistent provider appears to avoid the auxiliary lookup by source inspection, but was not executed as a workaround. ### REA version Source package 6.7.0, baseline commit `28a33cae8f8d4de8e11f7a266ff0d756432ab092`. ### Runtime and platform Linux x64 source inspection only. No REA, Node.js or JEB runtime execution. ### Target and artifact context Proposed public fixture: one `sample.dex` project unit. No APK, DEX or JEB project was executed or opened. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence No runtime output is claimed. The source proves the following chain: - [List handler](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/src/jeb/JebProvider.ts#L332-L368): the primary payload is parsed into `listed`, then `#engine` is awaited before result creation or `rawResult` retention. [Project open and decompilation](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/src/jeb/JebProvider.ts#L300-L407) use the same sequence. - [Metadata acquisition](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/src/jeb/JebProvider.ts#L233-L271): a fresh provider must await `get_client_information`. - [Connection cancellation](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/src/jeb/JebMcpConnection.ts#L246-L267) reaches the [deadline mapper](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/src/jeb/JebMcpDeadline.ts#L63-L83), which creates cancellation without a primary observation. - [Provider error conversion](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/src/jeb/JebProvider.ts#L437-L462) copies only the error's existing `partialObservation`. The local primary payload is never attached. The [shared service boundary](https://github.com/morluto/rea/blob/28a33cae8f8d4de8e11f7a266ff0d756432ab092/src/application/ProviderOperationExecution.ts#L75-L83) returns that error before Evidence assembly. ### Typed outcome or recovery expected Restoration signal for the proposed fixture: cancellation still identifies `list_jeb_units` and preserves the abort reason, and `partial_observation` contains the previously received `sample.dex` unit and its successful primary reply or equivalent explicitly partial representation. Do not fabricate engine metadata. The metadata-success control should still return complete Evidence. ### Analysis or suspected cause Source-derived cause: the completed primary reply remains only in handler-local variables while a fallible metadata lookup runs. The outer catch can access only the thrown error, so it cannot recover those variables. The shared Evidence completion handler is too late to retain them. ### Additional context Related closed [#4597](https://github.com/morluto/rea/issues/4597) concerns incorrect operation attribution after an auxiliary metadata refusal. Its expected behavior explicitly excludes requiring successful Evidence after that probe fails. This report instead requires retention of collected facts under cancellation, without converting cancellation to success. Closed [#3935](https://github.com/morluto/rea/issues/3935) concerns later CLI cleanup failures. Open [#4227](https://github.com/morluto/rea/issues/4227) is the general lifecycle audit. Open and closed issue searches covered JEB with `get_client_information`, `metadata`, `discard`, `partial`, and `cancellation`; no equivalent focused unresolved report was found. NOT_ENOUGH_INFO: introduction version and last known good version were not established. ## Triage assessment - Impact level: P2 - Assessment status: provisional - Impact basis: Source establishes loss of an already received primary analysis payload under a bounded cancellation sequence. Runtime occurrence and downstream consequences were not measured. - Workaround status: unverified - Workaround basis: Source suggests priming client metadata in the same persistent provider avoids this lookup, but no public runtime workaround or recovery of the discarded original observation was executed.

bsakaguchi closed this issue

2026-10-31 00:45:16 +00:00

bsakaguchi referenced this issue

2026-10-31 01:12:28 +00:00

[PR #4332] [CLOSED] fix(electron): resolve action target and crash execution via Page BrowserWindow handle #6177