morluto/rea

Fork 0

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

[GH-ISSUE #8744] [Bug] Kuna session advertises dossier after its required project has failed #7533

New issue

Open

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/8744

Before submitting

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

Area

Provider or capability discovery

Observed behavior

After a Kuna project export has definitively failed in a session, binary_session reports procedure_assembly unavailable once that operation fails, but still advertises analyze_function as available. Calling analyze_function immediately fails on the same settled project failure; only then does session status mark it unavailable. procedure_pseudo_code remains usable through a standalone run.

Reproduction

On REA 9ebbe67e05af08b567e215340da993c08dae378f, macOS arm64, Node 24.22.1 and released Kuna 1.989, use the owned two-function fixture and deliberate all-worker panic injection described in #8743. In one session:

Call procedure_assembly at 0x100000328 and wait for the project-failure error.
Call procedure_pseudo_code at the same address: standalone fallback succeeds.
Call binary_session: the capability groups report assembly unavailable but group analyze_function and pseudocode as available.
Call analyze_function for that address: it returns capability_unavailable due to the already failed project. Call binary_session again: analyze_function is now unavailable.

Observed with full and compact stdio MCP schemas. The faults were deliberately injected, not a natural failure estimate. Target SHA-256 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930 remained unchanged.

Expected behavior

When the selected Kuna session knows the project export has failed, make project-dependent operation readiness discoverable without requiring a trial call to each operation, while preserving standalone pseudocode availability. Alternatively explicitly distinguish declared capability support from observed runtime readiness. Keep unknown, transient, cancellation and cleanup states distinct; do not mark the whole provider unavailable.

Impact and scope

An agent consulting session capability availability is directed toward a dossier operation that cannot succeed until project recovery, costing a failed call. It can still use standalone pseudocode. This is one injected failure scenario; other failure modes, provider recovery, CLI and autonomous-agent behavior remain untested.

REA version

9ebbe67e05af08b567e215340da993c08dae378f

Runtime and platform

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

Target and artifact context

Owned unexecuted arm64 Mach-O; fresh REA Kuna cache.

Interface

MCP

Earliest failure stage

Session runtime availability projection

Relevant output or evidence

Before the dossier call: analyze_function and procedure_pseudo_code were grouped with available: true, while procedure_assembly was false. The dossier returned capability_unavailable; after that call it appeared in its own unavailable group.

Typed outcome or recovery expected

Show a known failed shared prerequisite at the right dependency scope, without conflating project-dependent operations with independent provider operations, or show that availability has not been verified. Retain the observed failure and recovery context.

Analysis or suspected cause

Source-derived: SessionRuntimeAvailability overlays AnalysisCapabilityUnavailableError on the operation that observed it. KunaSessionClient requires the same project for assembly and analyze_function, whereas pseudocode has an independent fallback. Treating this as a provider-wide error would incorrectly hide working operations. Availability is not a guarantee that arbitrary calls succeed; this control concerns a settled prerequisite failure already known to the provider session.

Additional context

Related #8743 concerns inaccessible project-failure records, and #8740 concerns fallback Evidence wording. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Working alternatives after the settled project failure

Using the same deliberately failed real Kuna 1.989 project and target, one session in each MCP profile called batch_decompile for both functions, decompile_all, and procedure_callees after the assembly error. Batch returned two successful standalone pseudocode items; directory export wrote two files, with no failed or remaining functions; the callees query succeeded with an empty result and the provider's call-coverage limitation. Batch and directory Evidence included the project-failure and single-function caveats; the directory index associated those caveats with both functions. The target hash remained unchanged. This is a working alternative for this fixture, not equivalence to a complete project dossier, proof of no callees, or a natural failure frequency. Main still has the contradictory single-function timing wording tracked by #8740.

Controlled repair and reopen

In separate fresh-cache compact and full MCP sessions, I used a test-only Kuna wrapper that injected the same project-worker panics while a local marker existed. After assembly and dossier failed, binary_session reported the dossier unavailable. I closed the binary, removed the marker (the wrapper executable itself was unchanged), reopened the same target in the same MCP server, and requested analyze_function. The new project completed, the dossier succeeded, and session capabilities reported it available again in both profiles. Target SHA-256 stayed 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930. This validates one explicitly repaired test condition and reopen, not automatic recovery or behavior across other failure types. A prior combined run reused a successful cache between profiles and was discarded; the reported runs used separate caches.

Real deadline recovery control

Using released Kuna 1.989 directly, without a fault-injection wrapper, I started fresh REA MCP servers with REA_KUNA_PROJECT_TIMEOUT_MS=10 and separate cache roots. In both compact and full profiles, procedure_assembly failed because the project's kuna functions inventory command did not complete within that deadline. The top-level error was capability_unavailable, retained provider_timeout as the underlying export code, and named both the setting and the need to restart REA and reopen the target. I closed the session and server, started a new server with the same cache and a 180,000 ms deadline, reopened the same target, and successfully requested its complete analyze_function dossier in each profile. The target SHA-256 remained 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930. This verifies one deliberately tiny deadline and its documented recovery, not natural timeout frequency or a timeout during the later decompile-project command.

Project-command deadline control

With real Kuna 1.989 on main 9ebbe67e, a test-only wrapper injected a worker stall during decompile-project, after inventory completed. In both full and compact stdio MCP profiles with a 1,500 ms REA_KUNA_PROJECT_TIMEOUT_MS, procedure_assembly returned capability_unavailable, retained the underlying provider_timeout, identified kuna decompile-project, and instructed a restart with a larger setting. After closing REA, removing the stall injection, starting a new server with a 180,000 ms deadline, and reopening the target, analyze_function succeeded in both profiles. The target SHA-256 remained 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930. This tests a deliberately injected stall and a combined repair (removing the stall and raising the deadline); it does not show that a larger deadline alone would have fixed the stall or establish natural timeout frequency.

Existing PR and background-failure control

On unmodified #8748 head 6d3f4c72de58bc75b39cff9df1fe8e3f4129f3a5, real Kuna 1.989 in compact and full MCP profiles reproduced the original control with the all-worker panic injection: after procedure_assembly reported the failure, session status marked both assembly and dossier unavailable while standalone pseudocode remained available. In separate fresh-cache controls, removing the test-only fault and reopening restored dossier availability and a successful result. The target hash remained unchanged.

A distinct fresh-cache control on that same PR head started only procedure_pseudo_code; it succeeded through the standalone path. After its raw_result.project_export.state explicitly became failed, binary_session still marked both assembly and dossier available in both profiles because no project-dependent call had yet reported the failure. No assembly or dossier call preceded this status check. This is a deliberately injected all-worker failure, not a natural frequency claim. Source inspection is consistent: the PR propagates sibling unavailability from an operation's failure, while a successful standalone observation does not emit that failure. The control leaves open whether the intended contract is to expose known background state immediately or only after a dependent request; it does not negate the PR's improvement to the original reported sequence.

Readiness ownership

Source inspection on #8748 6d3f4c72de58bc75b39cff9df1fe8e3f4129f3a5: the Kuna session already owns the current export state and exposes it in successful pseudocode raw metadata, while binary_session builds capability availability from route declarations and SessionRuntimeAvailability's observed operation outcomes. The proposed sibling-failure mechanism improves status after a dependent refusal but has no path for a background project failure observed only by the Kuna session. A complete solution would need a provider-owned, session-scoped readiness observation or an explicitly unknown readiness contract, propagated without treating standalone Kuna operations as failed; it must also address changes on completion, invalidation, close/reopen, composite routing, cleanup and notification semantics. This is source-derived design analysis, not a proposed implementation or evidence that any particular notification is currently promised.

Combined readiness and overflow recovery controls

A disposable, uncommitted merge of #8748 head 6d3f4c72de58bc75b39cff9df1fe8e3f4129f3a5 and #8747 head a8e7ce415e51b454580d677899b40719a7baf2ae built and passed two separate real Kuna 1.989 MCP controls in compact and full profiles. With test-only all-worker failure injection, assembly and dossier were unavailable after the assembly refusal, while standalone pseudocode remained available. With a separate test-only oversized standalone output and delayed project, the initial pseudocode failure was retryable, assembly completed the project, and retrying pseudocode succeeded. The target SHA-256 remained 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930. These are injected, separate failure scenarios; they do not resolve the background-readiness gap above or establish general integration coverage.

Recovery text in session availability

In the same deliberately injected all-worker failure on main 9ebbe67e, after procedure_assembly returned its failure, binary_session in both compact and full MCP profiles marked that operation unavailable and repeated Kuna's instruction to inspect per-function records. Unlike the operation error, the session availability reason did not include the advice to resolve the cause and reopen the target. In a separate test-only control, removing the injected fault did not make a repeated assembly call succeed in the same binary session, while closing and reopening the target did. The target was not executed and its SHA-256 remained 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930.

This identifies a recovery-context difference between the operation error and the session capability projection; it does not establish that the same remedy works for every failure or that diagnostic files are available. See #8743 for the removed-records issue. Any readiness design should keep recovery connected to the observed failure without assuming a universal retry remedy.

Producing boundary for lost recovery

Source-derived at 9ebbe67e: KunaSessionClient.exportUnavailable attaches the cause and recovery in the AnalysisCapabilityUnavailableError.userMessage; its base message is constructed separately from the provider, operation and raw reason. Shared SessionRuntimeAvailability.runtimeFailureReason records the base message for this error type, then the session status projection uses that recorded string. Thus the observed missing reopen guidance is not caused by Kuna failing to generate it. This shared projection can also discard distinct user-facing messages from other providers, but no separate real-provider reproduction has been performed. A correction should preserve the applicable user-facing recovery without asserting that a failure remains current after lifecycle changes or exposing cleanup-dependent actions as safe.

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8744 ### 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 Provider or capability discovery ### Observed behavior After a Kuna project export has definitively failed in a session, `binary_session` reports `procedure_assembly` unavailable once that operation fails, but still advertises `analyze_function` as available. Calling `analyze_function` immediately fails on the same settled project failure; only then does session status mark it unavailable. `procedure_pseudo_code` remains usable through a standalone run. ### Reproduction On REA `9ebbe67e05af08b567e215340da993c08dae378f`, macOS arm64, Node 24.22.1 and released Kuna 1.989, use the owned two-function fixture and deliberate all-worker panic injection described in #8743. In one session: 1. Call `procedure_assembly` at `0x100000328` and wait for the project-failure error. 2. Call `procedure_pseudo_code` at the same address: standalone fallback succeeds. 3. Call `binary_session`: the capability groups report assembly unavailable but group `analyze_function` and pseudocode as available. 4. Call `analyze_function` for that address: it returns `capability_unavailable` due to the already failed project. Call `binary_session` again: `analyze_function` is now unavailable. Observed with full and compact stdio MCP schemas. The faults were deliberately injected, not a natural failure estimate. Target SHA-256 `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930` remained unchanged. ### Expected behavior When the selected Kuna session knows the project export has failed, make project-dependent operation readiness discoverable without requiring a trial call to each operation, while preserving standalone pseudocode availability. Alternatively explicitly distinguish declared capability support from observed runtime readiness. Keep unknown, transient, cancellation and cleanup states distinct; do not mark the whole provider unavailable. ### Impact and scope An agent consulting session capability availability is directed toward a dossier operation that cannot succeed until project recovery, costing a failed call. It can still use standalone pseudocode. This is one injected failure scenario; other failure modes, provider recovery, CLI and autonomous-agent behavior remain untested. ### REA version `9ebbe67e05af08b567e215340da993c08dae378f` ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.989 behind a test-only fault wrapper. ### Target and artifact context Owned unexecuted arm64 Mach-O; fresh REA Kuna cache. ### Interface MCP ### Earliest failure stage Session runtime availability projection ### Relevant output or evidence Before the dossier call: `analyze_function` and `procedure_pseudo_code` were grouped with `available: true`, while `procedure_assembly` was false. The dossier returned `capability_unavailable`; after that call it appeared in its own unavailable group. ### Typed outcome or recovery expected Show a known failed shared prerequisite at the right dependency scope, without conflating project-dependent operations with independent provider operations, or show that availability has not been verified. Retain the observed failure and recovery context. ### Analysis or suspected cause Source-derived: `SessionRuntimeAvailability` overlays `AnalysisCapabilityUnavailableError` on the operation that observed it. `KunaSessionClient` requires the same project for assembly and `analyze_function`, whereas pseudocode has an independent fallback. Treating this as a provider-wide error would incorrectly hide working operations. Availability is not a guarantee that arbitrary calls succeed; this control concerns a settled prerequisite failure already known to the provider session. ### Additional context Related #8743 concerns inaccessible project-failure records, and #8740 concerns fallback Evidence wording. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Working alternatives after the settled project failure Using the same deliberately failed real Kuna 1.989 project and target, one session in each MCP profile called `batch_decompile` for both functions, `decompile_all`, and `procedure_callees` after the assembly error. Batch returned two successful standalone pseudocode items; directory export wrote two files, with no failed or remaining functions; the callees query succeeded with an empty result and the provider's call-coverage limitation. Batch and directory Evidence included the project-failure and single-function caveats; the directory index associated those caveats with both functions. The target hash remained unchanged. This is a working alternative for this fixture, not equivalence to a complete project dossier, proof of no callees, or a natural failure frequency. Main still has the contradictory single-function timing wording tracked by #8740. ### Controlled repair and reopen In separate fresh-cache compact and full MCP sessions, I used a test-only Kuna wrapper that injected the same project-worker panics while a local marker existed. After assembly and dossier failed, `binary_session` reported the dossier unavailable. I closed the binary, removed the marker (the wrapper executable itself was unchanged), reopened the same target in the same MCP server, and requested `analyze_function`. The new project completed, the dossier succeeded, and session capabilities reported it available again in both profiles. Target SHA-256 stayed `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930`. This validates one explicitly repaired test condition and reopen, not automatic recovery or behavior across other failure types. A prior combined run reused a successful cache between profiles and was discarded; the reported runs used separate caches. ### Real deadline recovery control Using released Kuna 1.989 directly, without a fault-injection wrapper, I started fresh REA MCP servers with `REA_KUNA_PROJECT_TIMEOUT_MS=10` and separate cache roots. In both compact and full profiles, `procedure_assembly` failed because the project's `kuna functions` inventory command did not complete within that deadline. The top-level error was `capability_unavailable`, retained `provider_timeout` as the underlying export code, and named both the setting and the need to restart REA and reopen the target. I closed the session and server, started a new server with the same cache and a 180,000 ms deadline, reopened the same target, and successfully requested its complete `analyze_function` dossier in each profile. The target SHA-256 remained `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930`. This verifies one deliberately tiny deadline and its documented recovery, not natural timeout frequency or a timeout during the later decompile-project command. ### Project-command deadline control With real Kuna 1.989 on main `9ebbe67e`, a test-only wrapper injected a worker stall during `decompile-project`, after inventory completed. In both full and compact stdio MCP profiles with a 1,500 ms `REA_KUNA_PROJECT_TIMEOUT_MS`, `procedure_assembly` returned `capability_unavailable`, retained the underlying `provider_timeout`, identified `kuna decompile-project`, and instructed a restart with a larger setting. After closing REA, removing the stall injection, starting a new server with a 180,000 ms deadline, and reopening the target, `analyze_function` succeeded in both profiles. The target SHA-256 remained `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930`. This tests a deliberately injected stall and a combined repair (removing the stall and raising the deadline); it does not show that a larger deadline alone would have fixed the stall or establish natural timeout frequency. ### Existing PR and background-failure control On unmodified #8748 head `6d3f4c72de58bc75b39cff9df1fe8e3f4129f3a5`, real Kuna 1.989 in compact and full MCP profiles reproduced the original control with the all-worker panic injection: after `procedure_assembly` reported the failure, session status marked both assembly and dossier unavailable while standalone pseudocode remained available. In separate fresh-cache controls, removing the test-only fault and reopening restored dossier availability and a successful result. The target hash remained unchanged. A distinct fresh-cache control on that same PR head started only `procedure_pseudo_code`; it succeeded through the standalone path. After its `raw_result.project_export.state` explicitly became `failed`, `binary_session` still marked both assembly and dossier available in both profiles because no project-dependent call had yet reported the failure. No assembly or dossier call preceded this status check. This is a deliberately injected all-worker failure, not a natural frequency claim. Source inspection is consistent: the PR propagates sibling unavailability from an operation's failure, while a successful standalone observation does not emit that failure. The control leaves open whether the intended contract is to expose known background state immediately or only after a dependent request; it does not negate the PR's improvement to the original reported sequence. ### Readiness ownership Source inspection on #8748 `6d3f4c72de58bc75b39cff9df1fe8e3f4129f3a5`: the Kuna session already owns the current export state and exposes it in successful pseudocode raw metadata, while `binary_session` builds capability availability from route declarations and `SessionRuntimeAvailability`'s observed operation outcomes. The proposed sibling-failure mechanism improves status after a dependent refusal but has no path for a background project failure observed only by the Kuna session. A complete solution would need a provider-owned, session-scoped readiness observation or an explicitly unknown readiness contract, propagated without treating standalone Kuna operations as failed; it must also address changes on completion, invalidation, close/reopen, composite routing, cleanup and notification semantics. This is source-derived design analysis, not a proposed implementation or evidence that any particular notification is currently promised. ### Combined readiness and overflow recovery controls A disposable, uncommitted merge of #8748 head `6d3f4c72de58bc75b39cff9df1fe8e3f4129f3a5` and #8747 head `a8e7ce415e51b454580d677899b40719a7baf2ae` built and passed two separate real Kuna 1.989 MCP controls in compact and full profiles. With test-only all-worker failure injection, assembly and dossier were unavailable after the assembly refusal, while standalone pseudocode remained available. With a separate test-only oversized standalone output and delayed project, the initial pseudocode failure was retryable, assembly completed the project, and retrying pseudocode succeeded. The target SHA-256 remained `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930`. These are injected, separate failure scenarios; they do not resolve the background-readiness gap above or establish general integration coverage. ### Recovery text in session availability In the same deliberately injected all-worker failure on main `9ebbe67e`, after `procedure_assembly` returned its failure, `binary_session` in both compact and full MCP profiles marked that operation unavailable and repeated Kuna's instruction to inspect per-function records. Unlike the operation error, the session availability reason did not include the advice to resolve the cause and reopen the target. In a separate test-only control, removing the injected fault did not make a repeated assembly call succeed in the same binary session, while closing and reopening the target did. The target was not executed and its SHA-256 remained `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930`. This identifies a recovery-context difference between the operation error and the session capability projection; it does not establish that the same remedy works for every failure or that diagnostic files are available. See #8743 for the removed-records issue. Any readiness design should keep recovery connected to the observed failure without assuming a universal retry remedy. ### Producing boundary for lost recovery Source-derived at `9ebbe67e`: `KunaSessionClient.exportUnavailable` attaches the cause and recovery in the `AnalysisCapabilityUnavailableError.userMessage`; its base `message` is constructed separately from the provider, operation and raw reason. Shared `SessionRuntimeAvailability.runtimeFailureReason` records the base `message` for this error type, then the session status projection uses that recorded string. Thus the observed missing reopen guidance is not caused by Kuna failing to generate it. This shared projection can also discard distinct user-facing messages from other providers, but no separate real-provider reproduction has been performed. A correction should preserve the applicable user-facing recovery without asserting that a failure remains current after lifecycle changes or exposing cleanup-dependent actions as safe.

bsakaguchi added the

bug

triage

labels

2026-11-03 08:19:42 +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#7533

No description provided.

Rows
Columns