morluto/rea

Fork 0

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

[GH-ISSUE #8736] [Bug] Batch null pseudocode is classified as an unsupported provider #7530

New issue

Closed

opened 2026-11-03 07:17:04 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 07:17:04 +00:00

Owner

Originally created by @morluto on GitHub (Nov 3, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8736

Before submitting

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

Area

MCP or agent integration

Observed behavior

batch_decompile maps a successful provider observation with null pseudocode to capability_unavailable / unsupported_provider, even when the per-item limitation identifies a worker watchdog failure. The per-item limitation and its guidance correctly expose the reason, but the error category states a broader provider-capability conclusion than the observation establishes.

Reproduction

On REA main 9ebbe67e05af08b567e215340da993c08dae378f, macOS arm64, Node 24.22.1 and Kuna 1.989, use the deliberately injected mixed-export fixture in #8167: a caller-owned wrapper injects KUNA_JOBS_FAULT=stall:0x100000328 into decompile-project, with a one-second per-function budget and two jobs. Let the project complete, then call batch_decompile with addresses: ["0x100000328"] and detail: "complete".

In both compact and full stdio MCP profiles the item has status: error, code: capability_unavailable, category: unsupported_provider, retryable: false, and details.reason: provider returned null pseudocode. Its own limitations correctly report that the worker stalled past the watchdog and was killed. In the same fixture, procedure_pseudo_code returns null with that limitation; analyze_function reports the pseudocode facet unavailable with the same reason and retains assembly. A direct single-function Kuna invocation succeeded in the earlier #8167 control. The fault is deliberately injected and does not establish natural frequency or that an immediate repeated REA call can recover; REA currently keeps using the completed project.

The self-built Mach-O was not executed and SHA-256 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930 remained unchanged.

Expected behavior

Represent the per-item observation and provider-reported failure without classifying the provider as unsupported solely because pseudocode is null. Preserve uncertainty when the reason or retryability is unknown, and preserve item order, provider limitations and successful sibling results. Do not infer retryability from arbitrary limitation text or assume an automatic retry is safe.

Impact and scope

An agent that routes on the structured category may conclude the provider lacks the capability even though the explicit limitation says the project worker stalled. No autonomous-agent decision or natural timeout was observed. One injected failure, one target and one platform were tested.

REA version

9ebbe67e05af08b567e215340da993c08dae378f

Runtime and platform

macOS arm64, Node 24.22.1, Kuna 1.989 through the deliberately instrumented wrapper, stdio MCP compact and full profiles.

Target and artifact context

Self-built arm64 Mach-O, unchanged and unexecuted.

Interface

MCP

Earliest failure stage

Analysis or provider dispatch

Relevant output or evidence

{status: "error", error: {code: "capability_unavailable", category: "unsupported_provider", retryable: false, details: {reason: "provider returned null pseudocode"}}, limitations: ["...worker stalled past the per-function watchdog (1s); the worker was killed"]}.

Analysis or suspected cause

Source-derived: EnhancedTools.ts maps every null pseudocode observation to AnalysisCapabilityUnavailableError, whose domain meaning is that a selected provider cannot execute the operation. Null may instead describe a missing body, a per-function failure, or an unclassified absence. A producer-owned reason can distinguish some cases, but arbitrary caveats are not typed failure reasons.

Contract design constraint

Source inspection: batch items currently use the shared analysisErrorProjectionSchema; the existing capability_unavailable code maps to unsupported_provider, while unreadable_output describes malformed or unusable output and previously produced misleading doctor guidance (#8226). Null is an admitted provider observation, so simply swapping between those existing categories would preserve a false explanation. A fix needs an explicit neutral missing-result outcome or error in the owning contract, with a deliberate policy for the existing boolean retryable field and the batch summary/view filters. Preserve already retained Evidence containing the previous item shape, and validate SDK-converted schemas and real clients. This is a design constraint from source, not a claim that the new representation has been implemented.

Typed outcome or recovery expected

A truthful per-item missing-result/failure representation, with known and unknown causes distinct, and no unsupported-provider claim without evidence. Verify unclassified null, external/no-body entries, worker failure, actual provider refusal, mixed batches, both schema profiles and source retention.

Additional context

Related #8226 fixed per-item limitation association; #8167 tracks explicit retry and #8731 concerns the bulk directory manifest. This report concerns the category of the current batch item, not loss of the limitation. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Mixed worker-panic control

The same misclassification occurs with an injected worker panic, not just the watchdog stall above. On REA 9ebbe67e, real Kuna 1.989 produced a completed project with one successful function and one failed worker. In compact and full MCP profiles, a two-address batch_decompile preserved the good sibling and the failed item's worker-exit limitation, but categorized that item as capability_unavailable / unsupported_provider. The failed function's assembly was available, and direct standalone Kuna decompilation of it succeeded in a separate process. Thus this specific result is a missing project body with a reported worker failure; it does not establish that the provider lacks decompilation support or that an automatic retry is safe. Successful replies validated against the advertised schemas. The deliberate fault was not a naturally observed panic; the unexecuted target SHA-256 stayed 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930.

PR control on the panic fixture

On #8737 current head 0e53cd2a2d2ccc56d747a4c1995cf87d9b1be4bc, real Kuna 1.989 with the same injected mixed worker panic returned status: unavailable, reason: no_pseudocode and the worker-failure limitation for the affected batch item; the other item remained ok. Compact and full MCP profiles both validated against fetched schemas. Exporting the batch and importing it into a fresh target-free server preserved the parent Evidence ID, failed item index, address, status, reason and worker limitation through a filtered retained view. The fixture was unchanged and never executed. This is a deliberately injected panic, not evidence of natural failure frequency.

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8736 ### 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 MCP or agent integration ### Observed behavior `batch_decompile` maps a successful provider observation with null pseudocode to `capability_unavailable` / `unsupported_provider`, even when the per-item limitation identifies a worker watchdog failure. The per-item limitation and its guidance correctly expose the reason, but the error category states a broader provider-capability conclusion than the observation establishes. ### Reproduction On REA main `9ebbe67e05af08b567e215340da993c08dae378f`, macOS arm64, Node 24.22.1 and Kuna 1.989, use the deliberately injected mixed-export fixture in #8167: a caller-owned wrapper injects `KUNA_JOBS_FAULT=stall:0x100000328` into `decompile-project`, with a one-second per-function budget and two jobs. Let the project complete, then call `batch_decompile` with `addresses: ["0x100000328"]` and `detail: "complete"`. In both compact and full stdio MCP profiles the item has `status: error`, `code: capability_unavailable`, `category: unsupported_provider`, `retryable: false`, and `details.reason: provider returned null pseudocode`. Its own limitations correctly report that the worker stalled past the watchdog and was killed. In the same fixture, `procedure_pseudo_code` returns null with that limitation; `analyze_function` reports the pseudocode facet unavailable with the same reason and retains assembly. A direct single-function Kuna invocation succeeded in the earlier #8167 control. The fault is deliberately injected and does not establish natural frequency or that an immediate repeated REA call can recover; REA currently keeps using the completed project. The self-built Mach-O was not executed and SHA-256 `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930` remained unchanged. ### Expected behavior Represent the per-item observation and provider-reported failure without classifying the provider as unsupported solely because pseudocode is null. Preserve uncertainty when the reason or retryability is unknown, and preserve item order, provider limitations and successful sibling results. Do not infer retryability from arbitrary limitation text or assume an automatic retry is safe. ### Impact and scope An agent that routes on the structured `category` may conclude the provider lacks the capability even though the explicit limitation says the project worker stalled. No autonomous-agent decision or natural timeout was observed. One injected failure, one target and one platform were tested. ### REA version `9ebbe67e05af08b567e215340da993c08dae378f` ### Runtime and platform macOS arm64, Node 24.22.1, Kuna 1.989 through the deliberately instrumented wrapper, stdio MCP compact and full profiles. ### Target and artifact context Self-built arm64 Mach-O, unchanged and unexecuted. ### Interface MCP ### Earliest failure stage Analysis or provider dispatch ### Relevant output or evidence `{status: "error", error: {code: "capability_unavailable", category: "unsupported_provider", retryable: false, details: {reason: "provider returned null pseudocode"}}, limitations: ["...worker stalled past the per-function watchdog (1s); the worker was killed"]}`. ### Analysis or suspected cause Source-derived: `EnhancedTools.ts` maps every null pseudocode observation to `AnalysisCapabilityUnavailableError`, whose domain meaning is that a selected provider cannot execute the operation. Null may instead describe a missing body, a per-function failure, or an unclassified absence. A producer-owned reason can distinguish some cases, but arbitrary caveats are not typed failure reasons. ### Contract design constraint Source inspection: batch items currently use the shared `analysisErrorProjectionSchema`; the existing `capability_unavailable` code maps to `unsupported_provider`, while `unreadable_output` describes malformed or unusable output and previously produced misleading doctor guidance (#8226). Null is an admitted provider observation, so simply swapping between those existing categories would preserve a false explanation. A fix needs an explicit neutral missing-result outcome or error in the owning contract, with a deliberate policy for the existing boolean `retryable` field and the batch summary/view filters. Preserve already retained Evidence containing the previous item shape, and validate SDK-converted schemas and real clients. This is a design constraint from source, not a claim that the new representation has been implemented. ### Typed outcome or recovery expected A truthful per-item missing-result/failure representation, with known and unknown causes distinct, and no unsupported-provider claim without evidence. Verify unclassified null, external/no-body entries, worker failure, actual provider refusal, mixed batches, both schema profiles and source retention. ### Additional context Related #8226 fixed per-item limitation association; #8167 tracks explicit retry and #8731 concerns the bulk directory manifest. This report concerns the category of the current batch item, not loss of the limitation. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Mixed worker-panic control The same misclassification occurs with an injected worker panic, not just the watchdog stall above. On REA `9ebbe67e`, real Kuna 1.989 produced a completed project with one successful function and one failed worker. In compact and full MCP profiles, a two-address `batch_decompile` preserved the good sibling and the failed item's worker-exit limitation, but categorized that item as `capability_unavailable` / `unsupported_provider`. The failed function's assembly was available, and direct standalone Kuna decompilation of it succeeded in a separate process. Thus this specific result is a missing project body with a reported worker failure; it does not establish that the provider lacks decompilation support or that an automatic retry is safe. Successful replies validated against the advertised schemas. The deliberate fault was not a naturally observed panic; the unexecuted target SHA-256 stayed `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930`. ### PR control on the panic fixture On #8737 current head `0e53cd2a2d2ccc56d747a4c1995cf87d9b1be4bc`, real Kuna 1.989 with the same injected mixed worker panic returned `status: unavailable`, `reason: no_pseudocode` and the worker-failure limitation for the affected batch item; the other item remained `ok`. Compact and full MCP profiles both validated against fetched schemas. Exporting the batch and importing it into a fresh target-free server preserved the parent Evidence ID, failed item index, address, status, reason and worker limitation through a filtered retained view. The fixture was unchanged and never executed. This is a deliberately injected panic, not evidence of natural failure frequency.

bsakaguchi closed this issue

2026-11-04 18:21:30 +00:00

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#7530

No description provided.

Rows
Columns