[GH-ISSUE #5910] [Bug] Limit errors omit adjustment controls and leave hard-coded ceilings unexplained #3586

New issue

Closed

opened 2026-10-31 00:42:08 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:42:08 +00:00

Owner

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

Before submitting

Searched open and closed issues; this is a focused follow-up to #5808 and #5598.
Removed credentials, private paths and sensitive target data.

Area

MCP or agent integration; shared CLI/MCP error projection.

Observed behavior

When a timeout or resource limit is hit, the returned error does not consistently tell an agent whether the limit can be adjusted, exactly how to adjust it, or whether it is a hard-coded implementation policy. An initial conservative default can become an unexplained permanent ceiling. Improving the prose alone is insufficient if the cap itself has no current justification.

Source baseline: d9767eb48f23cbf536dd437ab43fc69f875c5a56. Concrete examples:

Boundary	Current behavior and missing recovery
JEB deadline	Produces a generic `AnalysisTimeoutError`. Its returned remediation omits the existing `REA_JEB_MCP_TIMEOUT_MS` control, despite composition reading it.
JavaScript worker heap exhaustion	Returns generic memory advice instead of naming the existing per-call `max_heap_mb` input, its units/range and which memory boundary it changes. Increasing that input must not be advertised as fixing parent, transfer or fixed parser limits.
Normal MCP response overflow	One branch says “Use a larger MCP response budget” without naming `REA_MCP_MAX_RESPONSE_BYTES` or the restart boundary. Its generic transport remediation does not supply that setting either. The oversized-error fallback elsewhere already names it. Prefer retained Evidence/paging/export when available; distinguish receive-buffer policy from Node's single-string ceiling.
ASAR header admission	Header decode is hard-coded to 16 MiB. The final message says “Artifact is too large to process safely. Narrow the requested path or use a smaller artifact.” It does not explain that this is an index/header budget, whether the cap is configurable, or a supported route around it. Selecting fewer sources does not bypass the prerequisite archive-header admission. Review whether this ceiling is still appropriate.

The user's supplied Loom screenshot reports a 532 MB archive / approximately 102,600 files rejected on its header budget. This is user-provided context, not a reproduction performed in this audit. The screenshot's missed Electron findings are a separate coverage question.

Counterexample to preserve: Ghidra's 330,000 ms startup default already is adjustable, and its current startup error names REA_GHIDRA_STARTUP_TIMEOUT_MS, restart/reopen semantics and the separate client deadline. JavaScript's per-source timeout also already names analysis_timeout_ms. Do not report those as currently unconfigurable or remove their specific guidance.

Reproduction and relevant evidence

Executed on macOS arm64 with Node 24.18.0:

Expired an actual JebMcpDeadline(1) in a local producer/projection probe and inspected projectAnalysisError: remediation omitted REA_JEB_MCP_TIMEOUT_MS.
Constructed representative ASAR-limit and JavaScript-memory domain errors and inspected the canonical projection: confirmed generic recovery text. These are projection probes, not real archive/worker exhaustion reproductions or fresh MCP transport captures.
Ran npm run test:local -- src/domain/analysisErrorProjection.test.ts src/artifacts/AsarHeader.test.ts src/config.test.ts: 133 tests passed. Passing existing tests does not establish that the missing guidance is correct.
Source-wide syntactic inventory examined 1,700 non-test/non-fixture TypeScript files and found 4,393 new …Error / new …Failure expressions. This is an inventory, not 4,393 distinct user-visible messages or a manual verification of every path.

Expected behavior and success criteria

At each producing boundary, classify the limit as a caller-selected budget, configurable default, fixed implementation policy, inherited resource limit, or actual format/protocol/runtime ceiling. Review the justification: an initial number or assumed agent budget does not establish a permanent constraint. See tool-design limits.
Where a hard-coded value is only a provisional policy, consider a validated per-call override or configuration setting with the current value as its default. Consider bounded/streaming processing where that removes the admission bottleneck. Keep genuine allocation, format and lifecycle constraints enforced; do not blindly raise every number.
The error returned when the limit is hit must state the affected budget, effective value/units, exact existing parameter/setting and valid range, and how a change takes effect: next call, reconnect, restart, reopen or fresh analysis. Tell the agent it can make the adjustment within the caller's authorized scope; otherwise give the exact required change. Documentation-only guidance is insufficient.
For a retained hard-coded cap, say that this release has no runtime override, explain the reason, and give a supported alternative or an explicit blocker. Do not imply that extra host memory, waiting, source selection or a new output channel changes an unrelated cap. Do not direct an installed agent to silently patch REA source.
Preserve partial Evidence and cleanup ownership. Report completed-but-undeliverable output separately from failed analysis; distinguish host, REA and upstream-provider deadlines. Keep typed metadata and prose consistent through CLI/MCP projection, wrappers and delivery fallback. Any structured adjustment hint must come from the owning contract, not message-pattern guessing.
Verify actual emitted failure messages at public boundaries and corrected retries where possible, including unchanged-retry controls and timeout-plus-cleanup failures. For changes to limits or processing, measure representative completed tasks and report tokens, elapsed/CPU time and peak process-family memory, with cold/warm and unmeasured costs explicit.

Example desired wording for JEB, with values populated from the actual failing request:

This request reached REA's configured JEB deadline of N ms. Increase REA_JEB_MCP_TIMEOUT_MS in REA's launch environment and restart/reconnect REA to apply it. Allow execution, cleanup and delivery headroom in the outer MCP client deadline. Confirm outstanding work and cleanup before retrying.

This wording is proposed; exact safe retry/settlement guidance needs verification against the JEB owner.

RepoPrompt CE comparison

Read the local public CE repository at c394896cc0569b68568b5978c73b26c1c86ca753 and consulted DeepWiki. Source-derived comparison, not a live RepoPrompt application evaluation:

Execution error projection distinguishes settling work, settled timeout, detached work and unresponsive cleanup; busy replies include retry_after_ms.
Timeout policy separates execution, cancellation and delivery. CLI selection honors explicit timeouts and adds delivery margin to supported semantic waits.
Allowlisted settings support list/get/set/options, validation and old/new/applied reporting. This illustrates discoverable editability; it does not establish that every CE timeout is adjustable or require REA to add a global settings mutation tool.

DeepWiki included details from a different source state; the claims above were checked against the pinned local source.

Impact and scope

Agents may abandon adjustable analyses, repeat ineffective requests or recommend changing the wrong budget. Natural failure frequency and model recovery rates: NOT_ENOUGH_INFO; no live-agent evaluation or real Ghidra/JEB/large-Loom reproduction was performed in this audit.

Interface: CLI/MCP. Earliest demonstrated stage: transport/result projection (local producer/projection probes). No implementation changes, provider installation, target execution or configuration writes were performed. This issue does not grant integration authority for new capabilities. Related: #5808 (broader recovery-control audit), #5598 (client deadlines), #5836 (artifact boundary loss), #5631 (fixed-budget recovery).

Originally created by @morluto on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5910 ### Before submitting - [x] Searched open and closed issues; this is a focused follow-up to #5808 and #5598. - [x] Removed credentials, private paths and sensitive target data. ### Area MCP or agent integration; shared CLI/MCP error projection. ### Observed behavior When a timeout or resource limit is hit, the returned error does not consistently tell an agent **whether the limit can be adjusted, exactly how to adjust it, or whether it is a hard-coded implementation policy**. An initial conservative default can become an unexplained permanent ceiling. Improving the prose alone is insufficient if the cap itself has no current justification. Source baseline: `d9767eb48f23cbf536dd437ab43fc69f875c5a56`. Concrete examples: | Boundary | Current behavior and missing recovery | | --- | --- | | [JEB deadline](https://github.com/morluto/rea/blob/d9767eb48f23cbf536dd437ab43fc69f875c5a56/src/jeb/JebMcpDeadline.ts#L38) | Produces a generic `AnalysisTimeoutError`. Its returned remediation omits the existing `REA_JEB_MCP_TIMEOUT_MS` control, despite [composition](https://github.com/morluto/rea/blob/d9767eb48f23cbf536dd437ab43fc69f875c5a56/src/composition/jeb.ts#L18) reading it. | | [JavaScript worker heap exhaustion](https://github.com/morluto/rea/blob/d9767eb48f23cbf536dd437ab43fc69f875c5a56/src/javascript/analysis/JavaScriptAnalysisWorker.ts#L948) | Returns generic memory advice instead of naming the existing per-call `max_heap_mb` input, its units/range and which memory boundary it changes. Increasing that input must not be advertised as fixing parent, transfer or fixed parser limits. | | [Normal MCP response overflow](https://github.com/morluto/rea/blob/d9767eb48f23cbf536dd437ab43fc69f875c5a56/src/server/toolResult.ts#L178) | One branch says “Use a larger MCP response budget” without naming `REA_MCP_MAX_RESPONSE_BYTES` or the restart boundary. Its generic transport remediation does not supply that setting either. The oversized-error fallback elsewhere already names it. Prefer retained Evidence/paging/export when available; distinguish receive-buffer policy from Node's single-string ceiling. | | [ASAR header admission](https://github.com/morluto/rea/blob/d9767eb48f23cbf536dd437ab43fc69f875c5a56/src/artifacts/AsarHeader.ts#L347) | Header decode is hard-coded to 16 MiB. The final message says “Artifact is too large to process safely. Narrow the requested path or use a smaller artifact.” It does not explain that this is an index/header budget, whether the cap is configurable, or a supported route around it. Selecting fewer sources does not bypass the prerequisite archive-header admission. Review whether this ceiling is still appropriate. | The user's supplied Loom screenshot reports a 532 MB archive / approximately 102,600 files rejected on its header budget. This is user-provided context, **not a reproduction performed in this audit**. The screenshot's missed Electron findings are a separate coverage question. Counterexample to preserve: Ghidra's 330,000 ms startup default **already is adjustable**, and its current startup error names `REA_GHIDRA_STARTUP_TIMEOUT_MS`, restart/reopen semantics and the separate client deadline. JavaScript's per-source timeout also already names `analysis_timeout_ms`. Do not report those as currently unconfigurable or remove their specific guidance. ### Reproduction and relevant evidence Executed on macOS arm64 with Node 24.18.0: - Expired an actual `JebMcpDeadline(1)` in a local producer/projection probe and inspected `projectAnalysisError`: remediation omitted `REA_JEB_MCP_TIMEOUT_MS`. - Constructed representative ASAR-limit and JavaScript-memory domain errors and inspected the canonical projection: confirmed generic recovery text. These are projection probes, not real archive/worker exhaustion reproductions or fresh MCP transport captures. - Ran `npm run test:local -- src/domain/analysisErrorProjection.test.ts src/artifacts/AsarHeader.test.ts src/config.test.ts`: **133 tests passed**. Passing existing tests does not establish that the missing guidance is correct. - Source-wide syntactic inventory examined 1,700 non-test/non-fixture TypeScript files and found 4,393 `new …Error` / `new …Failure` expressions. This is an inventory, not 4,393 distinct user-visible messages or a manual verification of every path. ### Expected behavior and success criteria 1. At each producing boundary, classify the limit as a caller-selected budget, configurable default, fixed implementation policy, inherited resource limit, or actual format/protocol/runtime ceiling. Review the justification: an initial number or assumed agent budget does not establish a permanent constraint. See [tool-design limits](https://github.com/morluto/rea/blob/d9767eb48f23cbf536dd437ab43fc69f875c5a56/docs/tool-design.md#L65). 2. Where a hard-coded value is only a provisional policy, consider a validated per-call override or configuration setting with the current value as its default. Consider bounded/streaming processing where that removes the admission bottleneck. Keep genuine allocation, format and lifecycle constraints enforced; do not blindly raise every number. 3. **The error returned when the limit is hit** must state the affected budget, effective value/units, exact existing parameter/setting and valid range, and how a change takes effect: next call, reconnect, restart, reopen or fresh analysis. Tell the agent it can make the adjustment within the caller's authorized scope; otherwise give the exact required change. Documentation-only guidance is insufficient. 4. For a retained hard-coded cap, say that this release has no runtime override, explain the reason, and give a supported alternative or an explicit blocker. Do not imply that extra host memory, waiting, source selection or a new output channel changes an unrelated cap. Do not direct an installed agent to silently patch REA source. 5. Preserve partial Evidence and cleanup ownership. Report completed-but-undeliverable output separately from failed analysis; distinguish host, REA and upstream-provider deadlines. Keep typed metadata and prose consistent through CLI/MCP projection, wrappers and delivery fallback. Any structured adjustment hint must come from the owning contract, not message-pattern guessing. 6. Verify actual emitted failure messages at public boundaries and corrected retries where possible, including unchanged-retry controls and timeout-plus-cleanup failures. For changes to limits or processing, measure representative completed tasks and report tokens, elapsed/CPU time and peak process-family memory, with cold/warm and unmeasured costs explicit. Example desired wording for JEB, with values populated from the actual failing request: > This request reached REA's configured JEB deadline of N ms. Increase REA_JEB_MCP_TIMEOUT_MS in REA's launch environment and restart/reconnect REA to apply it. Allow execution, cleanup and delivery headroom in the outer MCP client deadline. Confirm outstanding work and cleanup before retrying. This wording is proposed; exact safe retry/settlement guidance needs verification against the JEB owner. ### RepoPrompt CE comparison Read the local public CE repository at `c394896cc0569b68568b5978c73b26c1c86ca753` and consulted [DeepWiki](https://deepwiki.com/search/audit-mcp-errors-recovery-guid_31a3fe3a-4705-48f4-bd9a-e1e170a79028). Source-derived comparison, not a live RepoPrompt application evaluation: - [Execution error projection](https://github.com/repoprompt/repoprompt-ce/blob/c394896cc0569b68568b5978c73b26c1c86ca753/Sources/RepoPrompt/Infrastructure/MCP/MCPConnectionManager.swift#L12127) distinguishes settling work, settled timeout, detached work and unresponsive cleanup; busy replies include `retry_after_ms`. - [Timeout policy](https://github.com/repoprompt/repoprompt-ce/blob/c394896cc0569b68568b5978c73b26c1c86ca753/Sources/RepoPromptShared/MCP/MCPTimeoutPolicy.swift#L3) separates execution, cancellation and delivery. [CLI selection](https://github.com/repoprompt/repoprompt-ce/blob/c394896cc0569b68568b5978c73b26c1c86ca753/Sources/RepoPromptMCP/Interactive/InteractiveMCPClientSession.swift#L964) honors explicit timeouts and adds delivery margin to supported semantic waits. - [Allowlisted settings](https://github.com/repoprompt/repoprompt-ce/blob/c394896cc0569b68568b5978c73b26c1c86ca753/Sources/RepoPrompt/Infrastructure/MCP/AppSettingsMCPService.swift#L38) support list/get/set/options, validation and old/new/applied reporting. This illustrates discoverable editability; it does not establish that every CE timeout is adjustable or require REA to add a global settings mutation tool. DeepWiki included details from a different source state; the claims above were checked against the pinned local source. ### Impact and scope Agents may abandon adjustable analyses, repeat ineffective requests or recommend changing the wrong budget. Natural failure frequency and model recovery rates: **NOT_ENOUGH_INFO**; no live-agent evaluation or real Ghidra/JEB/large-Loom reproduction was performed in this audit. Interface: CLI/MCP. Earliest demonstrated stage: transport/result projection (local producer/projection probes). No implementation changes, provider installation, target execution or configuration writes were performed. This issue does not grant integration authority for new capabilities. Related: #5808 (broader recovery-control audit), #5598 (client deadlines), #5836 (artifact boundary loss), #5631 (fixed-budget recovery).

bsakaguchi

2026-10-31 00:42:08 +00:00

closed this issue
added the
bug

triage
labels

bsakaguchi commented

2026-10-31 00:42:09 +00:00

Author

Owner

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

Closing as naming honesty done.

Thematic process PR #6099 squash-merged (8413ec08): report the effective regex heap and uncertain signal retry, with launch provenance recovered from /proc/self/environ + /proc/self/cmdline (opaque sources → unestablished). Other #5910 thematic PRs already landed earlier (MCP, ASAR, etc.).

Configurability of hard-coded ceilings (with defaults) is tracked separately on #6176 — not in scope for this issue.

@morluto commented on GitHub (Oct 21, 2026): Closing as **naming honesty** done. Thematic process PR #6099 squash-merged (`8413ec08`): report the effective regex heap and uncertain signal retry, with launch provenance recovered from `/proc/self/environ` + `/proc/self/cmdline` (opaque sources → unestablished). Other #5910 thematic PRs already landed earlier (MCP, ASAR, etc.). Configurability of hard-coded ceilings (with defaults) is tracked separately on #6176 — not in scope for this issue.

bsakaguchi referenced this issue

2026-10-31 01:09:49 +00:00

[PR #3586] feat(jvm): inspect JVM source-line & local-variable debug metadata (#2377) #5840

bsakaguchi referenced this issue

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

[PR #4473] feat(dex): inspect Android DEX source-line and local-variable debug metadata #6263

bsakaguchi referenced this issue

2026-11-01 21:11:07 +00:00

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