[GH-ISSUE #4600] [Bug] JEB repeatedly probes valid metadata when engine version is unknown #2388

Closed
opened 2026-10-17 21:04:02 +00:00 by bsakaguchi · 2 comments
Owner

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

Before submitting

  • Searched open/closed reports for JEB metadata cache, repeated client information and omitted version. #4597 concerns refusal attribution; #4227 is the general lifecycle audit.
  • No credentials or sensitive target data included.

Area

MCP or agent integration

Observed behavior

A valid JEB client-information reply with success: true, gui_client: false and no version is accepted, but each subsequent analysis probes client information again. When the next probe refuses, REA returns an error despite a successful primary reply and previously parsed valid metadata.

Reproduction

Executed npm run test:focused -- tests/boundary/mcp/jebMcp.test.ts with three new real HTTP-to-provider and SDK MCP controls at ece277b30. Result: 3 failed, 7 passed. For each of list units, decompile item and open project, one persistent provider receives:

  1. Successful primary reply; metadata succeeds without optional version; REA returns Evidence with unknown version.
  2. The same primary operation succeeds again. The fixture refuses any further metadata probe.
    Observed second calls fail. Each expected trace is [primary, get_client_information, primary]; the implementation makes an additional metadata call. Endpoint responses are simulated; no real JEB engine behavior is claimed.

Expected behavior

Cache successful parsed client-information presence independently of its optional version. Preserve version: null as unknown and the observed GUI flag. Explicit client inspection and availability refresh should still fetch current information. Existing non-null version caching already demonstrates the intended per-provider reuse policy.

Impact and scope

P2: redundant upstream requests can turn a successful repeated analysis into failure. Observed in all three controlled public MCP workflows; real-engine frequency and reconnect behavior are NOT_ENOUGH_INFO, unverified.

REA version

Main cd9252bc6 plus committed attribution fix ece277b30; package 6.5.0. The attribution fix does not change metadata cache admission.

Runtime and platform

Node 24.18.0/npm 11.16.0, macOS arm64.

Target and artifact context

Synthetic sample.dex and sample.apk names; no actual artifact or JEB project opened.

Interface

MCP

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Second SDK callTool returns isError: true instead of Evidence. Source: src/jeb/JebProvider.ts checks this.#identity.version === null before metadata acquisition, although clientInformation.version is optional. Cached unknown information is mistaken for no information.

Analysis or suspected cause

Source-derived: provider identity doubles as cache-validity representation. Retain the parsed metadata as its own owner and derive identity/engine projections from those facts; remove the optional-version sentinel and duplicated cache fields.

Additional context

Related #4597 and #4227. Tests assert complete primary raw payload and unknown version, and retain real protocol calls and cleanup. Reconnect invalidation, real JEB, CPU/memory and whole-agent token effects are not established by this report.

Originally created by @morluto on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4600 ### Before submitting - [x] Searched open/closed reports for JEB metadata cache, repeated client information and omitted version. #4597 concerns refusal attribution; #4227 is the general lifecycle audit. - [x] No credentials or sensitive target data included. ### Area MCP or agent integration ### Observed behavior A valid JEB client-information reply with `success: true`, `gui_client: false` and no version is accepted, but each subsequent analysis probes client information again. When the next probe refuses, REA returns an error despite a successful primary reply and previously parsed valid metadata. ### Reproduction Executed `npm run test:focused -- tests/boundary/mcp/jebMcp.test.ts` with three new real HTTP-to-provider and SDK MCP controls at ece277b30. Result: 3 failed, 7 passed. For each of list units, decompile item and open project, one persistent provider receives: 1. Successful primary reply; metadata succeeds without optional version; REA returns Evidence with unknown version. 2. The same primary operation succeeds again. The fixture refuses any further metadata probe. Observed second calls fail. Each expected trace is `[primary, get_client_information, primary]`; the implementation makes an additional metadata call. Endpoint responses are simulated; no real JEB engine behavior is claimed. ### Expected behavior Cache successful parsed client-information presence independently of its optional version. Preserve `version: null` as unknown and the observed GUI flag. Explicit client inspection and availability refresh should still fetch current information. Existing non-null version caching already demonstrates the intended per-provider reuse policy. ### Impact and scope P2: redundant upstream requests can turn a successful repeated analysis into failure. Observed in all three controlled public MCP workflows; real-engine frequency and reconnect behavior are NOT_ENOUGH_INFO, unverified. ### REA version Main cd9252bc6 plus committed attribution fix ece277b30; package 6.5.0. The attribution fix does not change metadata cache admission. ### Runtime and platform Node 24.18.0/npm 11.16.0, macOS arm64. ### Target and artifact context Synthetic sample.dex and sample.apk names; no actual artifact or JEB project opened. ### Interface MCP ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence Second SDK `callTool` returns `isError: true` instead of Evidence. Source: `src/jeb/JebProvider.ts` checks `this.#identity.version === null` before metadata acquisition, although `clientInformation.version` is optional. Cached unknown information is mistaken for no information. ### Analysis or suspected cause Source-derived: provider identity doubles as cache-validity representation. Retain the parsed metadata as its own owner and derive identity/engine projections from those facts; remove the optional-version sentinel and duplicated cache fields. ### Additional context Related #4597 and #4227. Tests assert complete primary raw payload and unknown version, and retain real protocol calls and cleanup. Reconnect invalidation, real JEB, CPU/memory and whole-agent token effects are not established by this report.
Author
Owner

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

Pushed the metadata correction in 67384b23e (following ece277b30 for #4597).

Successful parsed metadata presence is now separate from the optional version. Only required version/GUI facts are retained; identity and engine results derive from the same selected facts. Explicit inspection and availability probes still refresh them. The cache lifetime is the current fixed MCP connection; future reconnect support must bind metadata to its producing connection identity.

Baseline repeated-call MCP controls: 3 failed, 7 passed. Final affected suite: 58 passed across six files, including all three repeated operations with unknown version, explicit refresh, primary payload preservation and concurrent inspection identity. Static/docs/format/discovery/pre-push checks passed. The concurrent control caught a draft metadata resampling race (1 failed, 19 passed), fixed before publication.

Completed public SDK MCP comparison: two list calls against a real local HTTP simulation. Upstream calls fell from 4 to 3; normalized requested/provider/result/raw facts match after checking and normalizing the ephemeral endpoint. Four alternating warm repeats/build: elapsed baseline/candidate 0.5207/0.4992s, CPU 0.7743/0.7549s, sampled family RSS 375668736/373866496 bytes; raw reply-token medians 1088/1080 (cl100k_base). Opaque Evidence IDs and ports vary, so this does not establish token or speed improvement. First-process samples were separate; true cold cache, whole-agent/catalog/request/retry tokens and native-engine costs are unmeasured.

Overlap review confirms PR3754 also addresses this cache admission through session generations. Its broader reconnect changes were not integrated because retained cleanup/live status and late-abort precedence need additional work (#4603). No real JEB or spontaneous transport fault behavior is claimed; leaving this issue open for maintainer review.

<!-- gh-comment-id:6225580372 --> @morluto commented on GitHub (Oct 16, 2026): Pushed the metadata correction in 67384b23e (following ece277b30 for #4597). Successful parsed metadata presence is now separate from the optional version. Only required version/GUI facts are retained; identity and engine results derive from the same selected facts. Explicit inspection and availability probes still refresh them. The cache lifetime is the current fixed MCP connection; future reconnect support must bind metadata to its producing connection identity. Baseline repeated-call MCP controls: 3 failed, 7 passed. Final affected suite: 58 passed across six files, including all three repeated operations with unknown version, explicit refresh, primary payload preservation and concurrent inspection identity. Static/docs/format/discovery/pre-push checks passed. The concurrent control caught a draft metadata resampling race (1 failed, 19 passed), fixed before publication. Completed public SDK MCP comparison: two list calls against a real local HTTP simulation. Upstream calls fell from 4 to 3; normalized requested/provider/result/raw facts match after checking and normalizing the ephemeral endpoint. Four alternating warm repeats/build: elapsed baseline/candidate 0.5207/0.4992s, CPU 0.7743/0.7549s, sampled family RSS 375668736/373866496 bytes; raw reply-token medians 1088/1080 (cl100k_base). Opaque Evidence IDs and ports vary, so this does not establish token or speed improvement. First-process samples were separate; true cold cache, whole-agent/catalog/request/retry tokens and native-engine costs are unmeasured. Overlap review confirms PR3754 also addresses this cache admission through session generations. Its broader reconnect changes were not integrated because retained cleanup/live status and late-abort precedence need additional work (#4603). No real JEB or spontaneous transport fault behavior is claimed; leaving this issue open for maintainer review.
Author
Owner

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

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

  • 67384b23e: fix(jeb): cache parsed metadata independently of optional version.

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.

<!-- gh-comment-id:6255999294 --> @morluto commented on GitHub (Oct 18, 2026): <!-- rea-backlog-reconciliation-2026-10-19-4600 --> Closing as fixed on `main` after reconciling this report with the landed owner/consumer changes. - [67384b23e](https://github.com/morluto/rea/commit/67384b23e56e95da780d73f8e019f9c1585652f8): fix(jeb): cache parsed metadata independently of optional version. 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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#2388
No description provided.