[GH-ISSUE #727] [Docs] Explain Ghidra query deadlines and recovery after client cancellation #327

New issue

Closed

opened 2026-10-15 18:23:55 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:23:55 +00:00

Owner

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

Before submitting

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

Documentation location

docs/installation.md (Ghidra); docs/mcp-contracts.md (provider binding, progress/cancellation); README.md (Ghidra).

Problem

Opening the controlled native target returned in a few milliseconds, but the first binary_overview exceeded the pinned SDK default request deadline (67.20 s observed). The next function request returned cancelled and a later string search returned generic retry/doctor advice. Close/reopen and a final default-deadline retry did not provide a native answer; the latter timed out after 63.63 s.

On a separate connection with correctly applied 240 s request options, real Ghidra overview succeeded in 75.71 s and function analysis in 129 ms. This was functioning analysis with an environment-qualified startup/deadline mismatch, not persistent engine failure.

The installation guide says the startup deadline fails the open; distinguish logical target selection from the first query's engine readiness, the transport initialize deadline, and caller request deadlines.

Expected content

Explain the separate handshake, provider-startup, and per-call deadlines, and how existing clients can accommodate real first-query startup. Give an accurate pinned-SDK example and describe the supported post-cancellation recovery behavior. Relate progress to explicit client progress-token handling; this evaluation did not collect progress notifications and cannot claim they were absent.

Successful pinned-SDK control:

await client.callTool(
  { name: 'binary_overview', arguments: {} },
  { timeout: 240000 }
);

The example is a measured recovery setting, not a universal recommended timeout or automatic server-side extension. Keep backend failure/cancellation reasons actionable without adding setup grants, unrelated installs, or silent fallback.

Supporting evidence

REA 4.0.1 at the evaluated revision; Node 22.19.0 and SDK 2.3.1; Linux x64/WSL2; real Ghidra 12.1.4 read from an existing mounted NTFS distribution; native Linux JDK 21; two-CPU affinity and 512 MiB Java heap. No fresh Windows-native analysis was tested.

An initial nominal extended-deadline retry used the wrong third SDK argument and did not apply the option. That evaluator error is excluded from extended-deadline evidence. Only the correctly applied separate-cohort result above counts.

Additional context

Hands-on public CLI/MCP evaluation, findings F07. Baseline: REA 4.0.1, source revision c3bc38bf6c74d2175a4680530dcadd6cab0e7791; evaluation date 2026-10-06.

#441 concerned MCP initialize/entrypoint startup; this report concerns the first provider query after an already connected transport. #98 covers existing progress/cancellation support. No missing-progress implementation claim is made.

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/727 ### Before submitting - [x] I searched the open and closed issues and relevant pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Documentation location [docs/installation.md](https://github.com/morluto/rea/blob/c3bc38bf6c74d2175a4680530dcadd6cab0e7791/docs/installation.md) (Ghidra); [docs/mcp-contracts.md](https://github.com/morluto/rea/blob/c3bc38bf6c74d2175a4680530dcadd6cab0e7791/docs/mcp-contracts.md) (provider binding, progress/cancellation); [README.md](https://github.com/morluto/rea/blob/c3bc38bf6c74d2175a4680530dcadd6cab0e7791/README.md) (Ghidra). ### Problem Opening the controlled native target returned in a few milliseconds, but the first binary_overview exceeded the pinned SDK default request deadline (67.20 s observed). The next function request returned cancelled and a later string search returned generic retry/doctor advice. Close/reopen and a final default-deadline retry did not provide a native answer; the latter timed out after 63.63 s. On a separate connection with correctly applied 240 s request options, real Ghidra overview succeeded in 75.71 s and function analysis in 129 ms. This was functioning analysis with an environment-qualified startup/deadline mismatch, not persistent engine failure. The installation guide says the startup deadline fails the open; distinguish logical target selection from the first query's engine readiness, the transport initialize deadline, and caller request deadlines. ### Expected content Explain the separate handshake, provider-startup, and per-call deadlines, and how existing clients can accommodate real first-query startup. Give an accurate pinned-SDK example and describe the supported post-cancellation recovery behavior. Relate progress to explicit client progress-token handling; this evaluation did not collect progress notifications and cannot claim they were absent. Successful pinned-SDK control: ```js await client.callTool( { name: 'binary_overview', arguments: {} }, { timeout: 240000 } ); ``` The example is a measured recovery setting, not a universal recommended timeout or automatic server-side extension. Keep backend failure/cancellation reasons actionable without adding setup grants, unrelated installs, or silent fallback. ### Supporting evidence REA 4.0.1 at the evaluated revision; Node 22.19.0 and SDK 2.3.1; Linux x64/WSL2; real Ghidra 12.1.4 read from an existing mounted NTFS distribution; native Linux JDK 21; two-CPU affinity and 512 MiB Java heap. No fresh Windows-native analysis was tested. An initial nominal extended-deadline retry used the wrong third SDK argument and did not apply the option. That evaluator error is excluded from extended-deadline evidence. Only the correctly applied separate-cohort result above counts. ### Additional context Hands-on public CLI/MCP evaluation, findings F07. Baseline: REA 4.0.1, source revision [c3bc38bf6c74d2175a4680530dcadd6cab0e7791](https://github.com/morluto/rea/commit/c3bc38bf6c74d2175a4680530dcadd6cab0e7791); evaluation date 2026-10-06. [#441](https://github.com/morluto/rea/issues/441) concerned MCP initialize/entrypoint startup; this report concerns the first provider query after an already connected transport. [#98](https://github.com/morluto/rea/issues/98) covers existing progress/cancellation support. No missing-progress implementation claim is made.

bsakaguchi

2026-10-15 18:23:55 +00:00