morluto/rea

Fork 0

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

[GH-ISSUE #8740] [Bug] Kuna fallback Evidence describes a failed export as still building #7532

New issue

Closed

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

bsakaguchi commented

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

Owner

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

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

After a Kuna project export has failed, a successful single-function pseudocode result says the export was still building and that a later request can return project text. The same Evidence also says the project export failed and later requests use single-function runs. These statements conflict about the current session.

Reproduction

On REA main 9ebbe67e05af08b567e215340da993c08dae378f, macOS arm64, Node 24.22.1, and released Kuna 1.989, open an owned two-function Mach-O with a fresh cache. A test-only wrapper injects KUNA_JOBS_FAULT=panic:0x100000328,panic:0x100000340 into decompile-project, with --max-fn-seconds 1 --jobs-chunk 1 and two jobs. Call procedure_assembly for 0x100000328, which waits until the all-failed project exits nonzero. Then call procedure_pseudo_code for the same address in the same open session. It succeeds through ordinary single-function Kuna decompilation, but both contradictory limitations are returned. Both compact and full stdio MCP profiles reproduced this. Faults were injected deliberately; natural frequency is unknown.

Expected behavior

The returned Evidence should accurately identify the single-function source and its whole-program-context limitation, without claiming the failed project is still building or promising that a later request can return that project's text in this session. Preserve the explicit project failure and its applicable recovery guidance.

Impact and scope

An agent receives contradictory information about source readiness and possible later results. The code body itself was successfully returned; no correctness claim about it is made. Other platforms, failure types and autonomous-agent behavior were not tested.

REA version

9ebbe67e05af08b567e215340da993c08dae378f

Runtime and platform

macOS arm64; Node 24.22.1; Kuna 1.989 behind a test-only fault wrapper.

Target and artifact context

Owned, unexecuted arm64 Mach-O; SHA-256 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930, unchanged after the sessions.

Interface

MCP

Earliest failure stage

Evidence projection

Relevant output or evidence

The first limitation says the single-function run occurred "while the project export was still building" and "a later request ... can return the export's text". The next says "The project export failed, so later requests also use single-function runs". binary_session remained open.

Typed outcome or recovery expected

Preserve the source and its real context without inferring a project transition from a fixed message. The procedure_assembly error refers to Kuna's per-function records; the temporary failed build was cleaned up in this control. Availability of those records and appropriate project-recovery guidance merit separate examination.

Analysis or suspected cause

Source-derived: KUNA_SINGLE_FUNCTION_LIMITATION is unconditional, while KunaSessionClient.#pseudocode appends the settled export failure as a second limitation. #settledExportFailure is observed after the single-function result, so any wording about exact earlier timing needs care.

Additional context

Related #8167 concerns failures inside completed projects, and #8683 covers mode and source-context identity. This report concerns the contradictory failure-state description. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

In the same real Kuna 1.989 failure-and-fallback control, the successful standalone pseudocode Evidence also said larger buffered text remains accessible in a local project export, even though the project had failed and its staging was removed. Source inspection shows this caveat was shared unconditionally by standalone and project-export answers; the cached-span error path can identify an existing export file and range, while a standalone subprocess is a different source. PR #8742 also qualifies that shared statement and clarifies the provider guide. On the proposed branch, the real injected-failure control in both MCP profiles returned the qualified caveat and preserved the project-failure limitation; it did not generate an oversized standalone result.

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8740 ### 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 After a Kuna project export has failed, a successful single-function pseudocode result says the export was still building and that a later request can return project text. The same Evidence also says the project export failed and later requests use single-function runs. These statements conflict about the current session. ### Reproduction On REA main `9ebbe67e05af08b567e215340da993c08dae378f`, macOS arm64, Node 24.22.1, and released Kuna 1.989, open an owned two-function Mach-O with a fresh cache. A test-only wrapper injects `KUNA_JOBS_FAULT=panic:0x100000328,panic:0x100000340` into `decompile-project`, with `--max-fn-seconds 1 --jobs-chunk 1` and two jobs. Call `procedure_assembly` for `0x100000328`, which waits until the all-failed project exits nonzero. Then call `procedure_pseudo_code` for the same address in the same open session. It succeeds through ordinary single-function Kuna decompilation, but both contradictory limitations are returned. Both compact and full stdio MCP profiles reproduced this. Faults were injected deliberately; natural frequency is unknown. ### Expected behavior The returned Evidence should accurately identify the single-function source and its whole-program-context limitation, without claiming the failed project is still building or promising that a later request can return that project's text in this session. Preserve the explicit project failure and its applicable recovery guidance. ### Impact and scope An agent receives contradictory information about source readiness and possible later results. The code body itself was successfully returned; no correctness claim about it is made. Other platforms, failure types and autonomous-agent behavior were not tested. ### REA version `9ebbe67e05af08b567e215340da993c08dae378f` ### Runtime and platform macOS arm64; Node 24.22.1; Kuna 1.989 behind a test-only fault wrapper. ### Target and artifact context Owned, unexecuted arm64 Mach-O; SHA-256 `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930`, unchanged after the sessions. ### Interface MCP ### Earliest failure stage Evidence projection ### Relevant output or evidence The first limitation says the single-function run occurred "while the project export was still building" and "a later request ... can return the export's text". The next says "The project export failed, so later requests also use single-function runs". `binary_session` remained open. ### Typed outcome or recovery expected Preserve the source and its real context without inferring a project transition from a fixed message. The `procedure_assembly` error refers to Kuna's per-function records; the temporary failed build was cleaned up in this control. Availability of those records and appropriate project-recovery guidance merit separate examination. ### Analysis or suspected cause Source-derived: `KUNA_SINGLE_FUNCTION_LIMITATION` is unconditional, while `KunaSessionClient.#pseudocode` appends the settled export failure as a second limitation. `#settledExportFailure` is observed after the single-function result, so any wording about exact earlier timing needs care. ### Additional context Related #8167 concerns failures inside completed projects, and #8683 covers mode and source-context identity. This report concerns the contradictory failure-state description. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Related capacity caveat In the same real Kuna 1.989 failure-and-fallback control, the successful standalone pseudocode Evidence also said larger buffered text remains accessible in a local project export, even though the project had failed and its staging was removed. Source inspection shows this caveat was shared unconditionally by standalone and project-export answers; the cached-span error path can identify an existing export file and range, while a standalone subprocess is a different source. PR #8742 also qualifies that shared statement and clarifies the provider guide. On the proposed branch, the real injected-failure control in both MCP profiles returned the qualified caveat and preserved the project-failure limitation; it did not generate an oversized standalone result.

bsakaguchi added the

bug

triage

labels

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

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

No description provided.

Rows
Columns