morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #1720] [Bug] query tool calls die at a flat ~60s timeout, shorter than configured Ghidra startup timeout #576

New issue

Closed

opened 2026-10-15 18:26:20 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-15 18:26:20 +00:00

Owner

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

Area

MCP or agent integration

Observed behavior

When a query tool (search_strings, search_procedures, list_documents) ends up needing to start the Ghidra provider itself (e.g. because no live client currently backs the session -- see #1719), it fails at almost exactly 60 seconds, well under the ~21 minutes a cold import actually needs on a 25MB target, and well under REA_GHIDRA_STARTUP_TIMEOUT_MS (set to 2,700,000ms in this environment). open_binary's own health operation, by contrast, correctly waits the full configured startup timeout on the same target when it performs a genuine cold start.

Reproduction

Get an MCP session into a state where a query tool must start the client itself rather than reusing an already-started one (e.g. via the short-circuit in #1719, or any other path where client.start() ends up invoked from a query handler rather than from open_binary's health call).
Call search_strings / list_documents / search_procedures.
Observe failure at ~60.0xx seconds every time, with error MCP error -32001: Request timed out -- confirmed via exact millisecond timestamps read directly from the calling MCP client's own request log across 5 separate calls (60.031s, 58.918s, 57.206s, 55.721s, 60.025s, 60.007s, 60.015s).

Expected behavior

Any code path that calls client.start() should honor the same configured startup deadline (REA_GHIDRA_STARTUP_TIMEOUT_MS / startupTimeoutMs) regardless of which tool triggered it, not just open_binary's own health operation.

Impact and scope

Makes any query tool unreliable whenever it has to perform (or re-perform) a real provider startup rather than reusing an already-live client -- compounds badly with #1719, since every query after that short-circuit fires its own doomed 60s-capped startup attempt. Does not affect queries against an already-live, already-started client (those return normally).

REA version

6.3.0 (npm)

Runtime and platform

Node (spawned via a thin stdio proxy in front of rea mcp), Linux x86_64 (Ubuntu), Ghidra 12.1.4, JDK 21

Target and artifact context

PE/x86, ~25MB Borland Delphi executable

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Example captured tool-call state (from the calling MCP client's own session log):

tool: search_strings, status: error, duration: 60.031s
error: "MCP error -32001: Request timed out"

Concurrent calls issued around the same failing one instead surfaced:

error: {"error":{"code":"cancelled","category":"cancelled",
  "message":"Analysis was cancelled. Start it again when ready.",
  "details":{"operation":"search_strings","cleanup":"complete"}}}

Analysis or suspected cause

Hypothesis, not confirmed -- flagging per the issue template's guidance not to present this as fact. Possibly the calling MCP client (not rea itself) applies its own default per-request timeout to these calls, and only open_binary's underlying request/response exchange happens to emit progress notifications that reset it; unconfirmed whether the asymmetry is rea-side or client-side. Worth clarifying in docs/mcp-contracts.md either way, since the difference in behavior between open_binary and other client.start()-triggering calls is surprising regardless of root cause.

Additional context

Related: #1719 (the short-circuit that puts query tools into this situation in the first place).

Originally created by @paulhothersall on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1720 ### Area MCP or agent integration ### Observed behavior When a query tool (`search_strings`, `search_procedures`, `list_documents`) ends up needing to start the Ghidra provider itself (e.g. because no live client currently backs the session -- see #1719), it fails at almost exactly 60 seconds, well under the ~21 minutes a cold import actually needs on a 25MB target, and well under `REA_GHIDRA_STARTUP_TIMEOUT_MS` (set to 2,700,000ms in this environment). `open_binary`'s own `health` operation, by contrast, correctly waits the full configured startup timeout on the same target when it performs a genuine cold start. ### Reproduction 1. Get an MCP session into a state where a query tool must start the client itself rather than reusing an already-started one (e.g. via the short-circuit in #1719, or any other path where `client.start()` ends up invoked from a query handler rather than from `open_binary`'s `health` call). 2. Call `search_strings` / `list_documents` / `search_procedures`. 3. Observe failure at ~60.0xx seconds every time, with error `MCP error -32001: Request timed out` -- confirmed via exact millisecond timestamps read directly from the calling MCP client's own request log across 5 separate calls (60.031s, 58.918s, 57.206s, 55.721s, 60.025s, 60.007s, 60.015s). ### Expected behavior Any code path that calls `client.start()` should honor the same configured startup deadline (`REA_GHIDRA_STARTUP_TIMEOUT_MS` / `startupTimeoutMs`) regardless of which tool triggered it, not just `open_binary`'s own `health` operation. ### Impact and scope Makes any query tool unreliable whenever it has to perform (or re-perform) a real provider startup rather than reusing an already-live client -- compounds badly with #1719, since every query after that short-circuit fires its own doomed 60s-capped startup attempt. Does not affect queries against an already-live, already-started client (those return normally). ### REA version 6.3.0 (npm) ### Runtime and platform Node (spawned via a thin stdio proxy in front of `rea mcp`), Linux x86_64 (Ubuntu), Ghidra 12.1.4, JDK 21 ### Target and artifact context PE/x86, ~25MB Borland Delphi executable ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Example captured tool-call state (from the calling MCP client's own session log): ``` tool: search_strings, status: error, duration: 60.031s error: "MCP error -32001: Request timed out" ``` Concurrent calls issued around the same failing one instead surfaced: ``` error: {"error":{"code":"cancelled","category":"cancelled", "message":"Analysis was cancelled. Start it again when ready.", "details":{"operation":"search_strings","cleanup":"complete"}}} ``` ### Analysis or suspected cause Hypothesis, not confirmed -- flagging per the issue template's guidance not to present this as fact. Possibly the calling MCP client (not rea itself) applies its own default per-request timeout to these calls, and only `open_binary`'s underlying request/response exchange happens to emit progress notifications that reset it; unconfirmed whether the asymmetry is rea-side or client-side. Worth clarifying in `docs/mcp-contracts.md` either way, since the difference in behavior between `open_binary` and other `client.start()`-triggering calls is surprising regardless of root cause. ### Additional context Related: #1719 (the short-circuit that puts query tools into this situation in the first place).

bsakaguchi

2026-10-15 18:26:20 +00:00

closed this issue
added the
P1: high

area: mcp

bug
labels

bsakaguchi commented

2026-10-15 18:26:21 +00:00

Author

Owner

@Ghost-Kang commented on GitHub (Oct 12, 2026):

I looked into this on current main (fa87dd2aa). The ~60s cutoff comes from the MCP client's request deadline, not from REA, and #1877 already covers what REA can do about it.

Where the 60s comes from. REA never emits -32001 / Request timed out. That is the MCP SDK client's RequestTimeout, and its default per-request timeout is DEFAULT_REQUEST_TIMEOUT_MSEC = 60000. I reproduced the mechanism at small scale using REA's real createServer and a fake provider that sends ghidra_startup progress:

no progress token → the request times out at the client deadline
progress token, but no reset → still times out, even though notifications arrive
resetTimeoutOnProgress: true plus maxTotalTimeout → the request succeeds

open_binary does not start Ghidra. Its internal health call is answered by CompositeProvider without creating a provider client (src/application/binary/CompositeProvider.ts, the operation === "health" branch). The first Ghidra-backed query always performs the cold start, so any client with a fixed 60s deadline fails a cold start longer than that. #1719's fixes (#1776, #2014) make this less frequent but don't change it. This is by design, as described in docs/mcp-contracts.md → "Ghidra first-query deadlines and recovery".

What already works. Since #1877, a query sends "Waiting for Ghidra startup" progress every 10s while startup is pending. That only helps if the request carries _meta.progressToken, and only if the client is configured with resetTimeoutOnProgress: true and a maxTotalTimeout at or above REA_GHIDRA_STARTUP_TIMEOUT_MS. @paulhothersall, if your client or proxy can forward progress tokens and set those options, a 21-minute cold import should complete. If it can't, see the next point.

Remaining gap (maintainer decision). When the client times out it sends notifications/cancelled. REA then aborts the shared startup, and queries that joined it report cancelled, which matches the second error in the report. So under a hard 60s client cap, every retry starts from zero, and a long import can never finish through MCP. Supporting such clients would mean letting a session-owned startup outlive the cancelled caller, or returning a typed retryable "provider starting" error. Either one changes the documented "cancellation propagates to provider work" contract, so I'd treat it as a separate design issue.

Unless that design change is wanted here, this issue looks resolved by #1877 plus the client-side settings above.

@Ghost-Kang commented on GitHub (Oct 12, 2026): I looked into this on current `main` (`fa87dd2aa`). The ~60s cutoff comes from the MCP client's request deadline, not from REA, and #1877 already covers what REA can do about it. **Where the 60s comes from.** REA never emits `-32001` / `Request timed out`. That is the MCP SDK client's `RequestTimeout`, and its default per-request timeout is `DEFAULT_REQUEST_TIMEOUT_MSEC = 60000`. I reproduced the mechanism at small scale using REA's real `createServer` and a fake provider that sends `ghidra_startup` progress: - no progress token → the request times out at the client deadline - progress token, but no reset → still times out, even though notifications arrive - `resetTimeoutOnProgress: true` plus `maxTotalTimeout` → the request succeeds **`open_binary` does not start Ghidra.** Its internal `health` call is answered by `CompositeProvider` without creating a provider client (`src/application/binary/CompositeProvider.ts`, the `operation === "health"` branch). The first Ghidra-backed query always performs the cold start, so any client with a fixed 60s deadline fails a cold start longer than that. #1719's fixes (#1776, #2014) make this less frequent but don't change it. This is by design, as described in `docs/mcp-contracts.md` → "Ghidra first-query deadlines and recovery". **What already works.** Since #1877, a query sends "Waiting for Ghidra startup" progress every 10s while startup is pending. That only helps if the request carries `_meta.progressToken`, and only if the client is configured with `resetTimeoutOnProgress: true` and a `maxTotalTimeout` at or above `REA_GHIDRA_STARTUP_TIMEOUT_MS`. @paulhothersall, if your client or proxy can forward progress tokens and set those options, a 21-minute cold import should complete. If it can't, see the next point. **Remaining gap (maintainer decision).** When the client times out it sends `notifications/cancelled`. REA then aborts the shared startup, and queries that joined it report `cancelled`, which matches the second error in the report. So under a hard 60s client cap, every retry starts from zero, and a long import can never finish through MCP. Supporting such clients would mean letting a session-owned startup outlive the cancelled caller, or returning a typed retryable "provider starting" error. Either one changes the documented "cancellation propagates to provider work" contract, so I'd treat it as a separate design issue. Unless that design change is wanted here, this issue looks resolved by #1877 plus the client-side settings above.

bsakaguchi commented

2026-10-15 18:26:21 +00:00

Author

Owner

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

Closing the REA-side 60-second-cutoff report as resolved by #1877 and the documented caller request policy, consistent with the later diagnosis in this thread. Current main is fffb07419.

A fresh scaled probe used the actual pinned MCP SDK 2.3.1 and production REA server with a controlled waiting provider: a 200 ms client deadline timed out in about 203 ms without a progress token, and in about 203 ms with progress but no reset; both cancellations reached the provider. With resetTimeoutOnProgress: true and maxTotalTimeout: 1000, the same approximately 497 ms operation completed. The current SDK labels this client failure REQUEST_TIMEOUT; the original older SDK reported -32001.

The first-query deadline guidance explains the separate client/provider owners and the second-argument callTool options. Raising REA_GHIDRA_STARTUP_TIMEOUT_MS cannot raise an external client's deadline. This probe did not run the original Ghidra target or claim a 21-minute import reproduction.

Letting startup outlive a cancelled caller would be a separate session-lifecycle design change. Current cancellation propagation remains intact; this closure does not claim that such asynchronous startup was implemented.

@morluto commented on GitHub (Oct 14, 2026): Closing the REA-side 60-second-cutoff report as resolved by #1877 and the documented caller request policy, consistent with the later diagnosis in this thread. Current main is [fffb07419](https://github.com/morluto/rea/commit/fffb0741936067530d1ce9777461cd53e87398c2). A fresh scaled probe used the actual pinned MCP SDK 2.3.1 and production REA server with a controlled waiting provider: a 200 ms client deadline timed out in about 203 ms without a progress token, and in about 203 ms with progress but no reset; both cancellations reached the provider. With `resetTimeoutOnProgress: true` and `maxTotalTimeout: 1000`, the same approximately 497 ms operation completed. The current SDK labels this client failure `REQUEST_TIMEOUT`; the original older SDK reported `-32001`. The [first-query deadline guidance](https://github.com/morluto/rea/blob/fffb0741936067530d1ce9777461cd53e87398c2/docs/mcp-contracts.md#ghidra-first-query-deadlines-and-recovery) explains the separate client/provider owners and the second-argument `callTool` options. Raising `REA_GHIDRA_STARTUP_TIMEOUT_MS` cannot raise an external client's deadline. This probe did not run the original Ghidra target or claim a 21-minute import reproduction. Letting startup outlive a cancelled caller would be a separate session-lifecycle design change. Current cancellation propagation remains intact; this closure does not claim that such asynchronous startup was implemented.

bsakaguchi commented

2026-10-15 18:26:21 +00:00

Author

Owner

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

The earlier closure was premature: caller ownership alone did not establish that REA's generated client settings or upstream SDK consumers were correct. Those gaps are now fixed in main bb4925252.

Codex/Kimi setup supplies missing tool deadlines from the known provider allowance plus 120 seconds of operation headroom: 450 seconds by default, or 2820 seconds with REA_GHIDRA_STARTUP_TIMEOUT_MS=2700000. Positive stored choices are preserved; doctor recommends an explicit value when they are too short. Actual CLI setup now forwards the selected settings instead of dropping them.
JEB's upstream SDK deadline is explicitly configurable with REA_JEB_MCP_TIMEOUT_MS; caller/connection cancellation remains distinct from timeout. IDA now retains SDK timeout identity as provider_timeout.
Pinned SDK 2.3.1 checks maxTotalTimeout on progress resets, without a separate absolute timer. The deadline guidance now explains an independent abort deadline and client settings. A server still cannot override an external caller's cap.

Full current-head qualification 38641869634 passed, alongside actual SDK HTTP/timer and compiled CLI regressions. Controlled probes establish the deadline mechanics, not the prevalence of timeouts or a rerun of the original 21-minute Ghidra import. Cancellation still propagates to provider work; session-owned background startup was not introduced.

Closing the corrected REA integration gap with those verification limits.

@morluto commented on GitHub (Oct 14, 2026): The earlier closure was premature: caller ownership alone did not establish that REA's generated client settings or upstream SDK consumers were correct. Those gaps are now fixed in main [`bb4925252`](https://github.com/morluto/rea/commit/bb49252523d13c48e6d3fb7c4cfd5f95400fcd53). - Codex/Kimi setup supplies missing tool deadlines from the known provider allowance plus 120 seconds of operation headroom: 450 seconds by default, or 2820 seconds with `REA_GHIDRA_STARTUP_TIMEOUT_MS=2700000`. Positive stored choices are preserved; doctor recommends an explicit value when they are too short. Actual CLI setup now forwards the selected settings instead of dropping them. - JEB's upstream SDK deadline is explicitly configurable with `REA_JEB_MCP_TIMEOUT_MS`; caller/connection cancellation remains distinct from timeout. IDA now retains SDK timeout identity as `provider_timeout`. - Pinned SDK 2.3.1 checks `maxTotalTimeout` on progress resets, without a separate absolute timer. The [deadline guidance](https://github.com/morluto/rea/blob/bb49252523d13c48e6d3fb7c4cfd5f95400fcd53/docs/mcp-contracts.md#ghidra-first-query-deadlines-and-recovery) now explains an independent abort deadline and client settings. A server still cannot override an external caller's cap. Full current-head qualification [38641869634](https://github.com/morluto/rea/actions/runs/38641869634) passed, alongside actual SDK HTTP/timer and compiled CLI regressions. Controlled probes establish the deadline mechanics, not the prevalence of timeouts or a rerun of the original 21-minute Ghidra import. Cancellation still propagates to provider work; session-owned background startup was not introduced. Closing the corrected REA integration gap with those verification limits.

bsakaguchi commented

2026-10-15 18:26:21 +00:00

Author

Owner

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

A further stopping probe found and fixed an IDA-specific client-budget omission in fa318995f. An explicit IDA registration allowing a 1,800,001 ms request still generated a 450-second Codex/Kimi deadline. Setup and doctor now consume the registration owner's parsed budget from the effective per-client environment, including stored file paths; missing deadlines include that allowance plus operation headroom. Existing positive caller deadlines remain unchanged, and credentials stay in the IDA file.

The compiled CLI regression failed on baseline for both clients and now covers 1,921-second Codex / 1,920,001 ms Kimi defaults, auto selection, changed stored budgets without ambient IDA settings, doctor recommendations, no-op repeated setup and meaningful malformed-registration errors without writes. Focused checks passed 110 tests; full exact-head qualification: https://github.com/morluto/rea/actions/runs/38655170737. No commercial IDA engine or original 21-minute Ghidra import was rerun for this configuration fix.

The SDK conclusion remains: request timeouts are adjustable, and the server cannot override a caller's cap. No measurement establishes that most REA workloads time out. The delivered configuration and SDK-boundary fixes address confirmed integration gaps rather than assume workload prevalence.

@morluto commented on GitHub (Oct 14, 2026): A further stopping probe found and fixed an IDA-specific client-budget omission in [`fa318995f`](https://github.com/morluto/rea/commit/fa318995f5654b2c2cb76f496da9220d49fc12ca). An explicit IDA registration allowing a 1,800,001 ms request still generated a 450-second Codex/Kimi deadline. Setup and doctor now consume the registration owner's parsed budget from the effective per-client environment, including stored file paths; missing deadlines include that allowance plus operation headroom. Existing positive caller deadlines remain unchanged, and credentials stay in the IDA file. The compiled CLI regression failed on baseline for both clients and now covers 1,921-second Codex / 1,920,001 ms Kimi defaults, `auto` selection, changed stored budgets without ambient IDA settings, doctor recommendations, no-op repeated setup and meaningful malformed-registration errors without writes. Focused checks passed 110 tests; full exact-head qualification: https://github.com/morluto/rea/actions/runs/38655170737. No commercial IDA engine or original 21-minute Ghidra import was rerun for this configuration fix. The SDK conclusion remains: request timeouts are adjustable, and the server cannot override a caller's cap. No measurement establishes that most REA workloads time out. The delivered configuration and SDK-boundary fixes address confirmed integration gaps rather than assume workload prevalence.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:13:59 +00:00

[PR #576] [MERGED] fix(javascript): preserve literal CommonJS path punctuation #2077

bsakaguchi referenced this issue

2026-10-16 21:14:00 +00:00

[PR #578] [MERGED] fix(artifacts): resolve parents after archive enumeration #2079