[GH-ISSUE #8746] [Bug] Kuna standalone overflow recovery overlooks a pending project export #7534

New issue

Closed

opened 2026-11-03 08:19:42 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 08:19:42 +00:00

Owner

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

Before submitting

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

Area

Native analysis or decompilation

Observed behavior

A cold Kuna single-function pseudocode request that exceeds REA's output buffer reports retryable: false and says repeating the request for the target fails the same way, recommending another provider. In a controlled session where the background project subsequently finishes, the same pseudocode request succeeds from the project export without changing provider or target.

Reproduction

On #8742 head d2859517d9071828eb65e42df9b25e3011f6aa2a (the relevant command failure logic is unchanged from main), macOS arm64, Node 24.22.1 and real Kuna 1.989, use an owned arm64 Mach-O and a fresh cache. An owned test wrapper delays decompile-project by three seconds, delegates project generation to real Kuna, and emits a synthetic 16 MiB + 1 byte body for the standalone decompile command.

Open the target with Kuna and call procedure_pseudo_code for 0x100000328 immediately. It returns resource_constraint, retryable: false, a 16,777,216-byte limit and the remediation saying repeat fails the same way and to use another provider.
Call procedure_assembly for the same function to wait for the real project to complete.
Repeat the same procedure_pseudo_code request. It succeeds; raw source metadata identifies project-export, and project state is ready.

Both full and compact stdio MCP profiles showed this. Target SHA-256 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930 remained unchanged and the target was not executed. The overflow and scheduling were deliberately synthetic; natural output size, frequency, and equivalence of independently generated pseudocode are not established.

Expected behavior

Preserve the actual fixed standalone output limit, but do not predict the outcome of the same high-level request if its provider source can change. When a project is still pending, communicate that it may later serve the request and how to observe readiness; when it has definitively failed or the project-export span itself exceeds capacity, preserve the applicable limitation and alternative. Keep retryability and cancellation/cleanup semantics truthful.

Impact and scope

An agent can be directed to switch providers even though the selected provider later supplies the same requested function from a different source. This does not prove the standalone and project output are semantically equivalent. Tested one controlled target, one host and both MCP profiles; CLI and autonomous-agent behavior are untested.

REA version

PR #8742 d2859517d9071828eb65e42df9b25e3011f6aa2a, based on main 9ebbe67e05af08b567e215340da993c08dae378f.

Runtime and platform

Node 24.22.1; macOS arm64; Kuna 1.989 behind the described synthetic-output scheduling wrapper.

Target and artifact context

Owned unexecuted arm64 Mach-O; isolated fresh cache.

Interface

MCP

Earliest failure stage

Provider failure projection and recovery

Relevant output or evidence

First call: resource_constraint, resource: memory, output_limit_bytes: 16777216, retryable: false, remediation repeating this request for this target fails the same way. Second call after assembly awaited project: successful pseudocode with raw_result.source.kind: project-export and project_export.state: ready.

Typed outcome or recovery expected

Keep an output-limit observation distinct from the future readiness of a project or the outcome of a later high-level call. Avoid unsupported certainty and silent provider changes.

Analysis or suspected cause

Source-derived: KunaCommand assigns the same fixed-buffer recovery to every subprocess output-limit failure. KunaSessionClient can instead route a later pseudocode request to a finished project. Any correction should account for the actual project state at the owning boundary and not weaken stable oversized-span handling.

Additional context

Related #8740 and #8742 cover misleading successful fallback limitations; this report concerns error recovery. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8746 ### 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 Native analysis or decompilation ### Observed behavior A cold Kuna single-function pseudocode request that exceeds REA's output buffer reports `retryable: false` and says repeating the request for the target fails the same way, recommending another provider. In a controlled session where the background project subsequently finishes, the same pseudocode request succeeds from the project export without changing provider or target. ### Reproduction On #8742 head `d2859517d9071828eb65e42df9b25e3011f6aa2a` (the relevant command failure logic is unchanged from main), macOS arm64, Node 24.22.1 and real Kuna 1.989, use an owned arm64 Mach-O and a fresh cache. An owned test wrapper delays `decompile-project` by three seconds, delegates project generation to real Kuna, and emits a synthetic 16 MiB + 1 byte body for the standalone `decompile` command. 1. Open the target with Kuna and call `procedure_pseudo_code` for `0x100000328` immediately. It returns `resource_constraint`, `retryable: false`, a 16,777,216-byte limit and the remediation saying repeat fails the same way and to use another provider. 2. Call `procedure_assembly` for the same function to wait for the real project to complete. 3. Repeat the same `procedure_pseudo_code` request. It succeeds; raw source metadata identifies `project-export`, and project state is ready. Both full and compact stdio MCP profiles showed this. Target SHA-256 `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930` remained unchanged and the target was not executed. The overflow and scheduling were deliberately synthetic; natural output size, frequency, and equivalence of independently generated pseudocode are not established. ### Expected behavior Preserve the actual fixed standalone output limit, but do not predict the outcome of the same high-level request if its provider source can change. When a project is still pending, communicate that it may later serve the request and how to observe readiness; when it has definitively failed or the project-export span itself exceeds capacity, preserve the applicable limitation and alternative. Keep retryability and cancellation/cleanup semantics truthful. ### Impact and scope An agent can be directed to switch providers even though the selected provider later supplies the same requested function from a different source. This does not prove the standalone and project output are semantically equivalent. Tested one controlled target, one host and both MCP profiles; CLI and autonomous-agent behavior are untested. ### REA version PR #8742 `d2859517d9071828eb65e42df9b25e3011f6aa2a`, based on main `9ebbe67e05af08b567e215340da993c08dae378f`. ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.989 behind the described synthetic-output scheduling wrapper. ### Target and artifact context Owned unexecuted arm64 Mach-O; isolated fresh cache. ### Interface MCP ### Earliest failure stage Provider failure projection and recovery ### Relevant output or evidence First call: `resource_constraint`, `resource: memory`, `output_limit_bytes: 16777216`, `retryable: false`, remediation `repeating this request for this target fails the same way`. Second call after assembly awaited project: successful pseudocode with `raw_result.source.kind: project-export` and `project_export.state: ready`. ### Typed outcome or recovery expected Keep an output-limit observation distinct from the future readiness of a project or the outcome of a later high-level call. Avoid unsupported certainty and silent provider changes. ### Analysis or suspected cause Source-derived: `KunaCommand` assigns the same fixed-buffer recovery to every subprocess output-limit failure. `KunaSessionClient` can instead route a later pseudocode request to a finished project. Any correction should account for the actual project state at the owning boundary and not weaken stable oversized-span handling. ### Additional context Related #8740 and #8742 cover misleading successful fallback limitations; this report concerns error recovery. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

bug

triage

labels

2026-11-03 08:19:42 +00:00

bsakaguchi closed this issue

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

bsakaguchi referenced this issue

2026-11-05 01:48:11 +00:00

[PR #7470] fix(adb)!: reject malformed package numeric tokens #7859