morluto/rea

Fork 0

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

[GH-ISSUE #8167] [Feature] Recover individual Kuna decompiles that fail in a completed project export #4693

New issue

Open

opened 2026-10-31 00:52:32 +00:00 by bsakaguchi · 10 comments

bsakaguchi commented

2026-10-31 00:52:32 +00:00

Owner

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

Independent-attempt timeout and concurrency controls

On the same uncommitted independent-retry prototype, a test-only wrapper ran an inspectable stalled Node process in place of the standalone decompiler, with REA_KUNA_TIMEOUT_MS=500. In both MCP profiles the explicit attempt returned provider_timeout; the original completed-project observation remained null, and after removing the stall a later explicit fresh Kuna attempt returned pseudocode. Both the original and later successful Evidence records were retained. The timeout error itself was not shown to become an Evidence record. The target SHA-256 0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930 remained unchanged and the target was not run.

A separate compact-profile control issued two concurrent fresh requests for the same function. The test wrapper recorded two standalone decompile launches; both succeeded and produced the same content-addressed Evidence ID. This is the prototype's current behavior, not a chosen concurrency contract: coalescing, explicit run receipts, admission bounds and cancellation of one versus both callers still require design and verification. Neither test establishes real Kuna timeout behavior or cross-platform cleanup.

Prototype discovery and CLI controls

The isolated prototype was extended to project its provider declaration through grouped binary_session capabilities and to expose the selection on the existing rea decompile command. With real Kuna 1.989 and Ghidra 12.1.4 in both MCP schema profiles, summary and complete status reported the declaration for Kuna's pseudocode operation and omitted it for Ghidra; the explicit request succeeded with Kuna and was refused with Ghidra. The SDK-advertised input and output schemas validated and successful status/results matched them. On the warm mixed-failure cache, real CLI decompile --analysis independent_fresh returned the standalone body and its context limitation; the ordinary CLI command returned the project's null body and worker-failure limitation.

The first discovery version put guidance only in the input field description. The compact schema omitted that description, so the tool description did not explain the choice there. After adding the guidance to the tool description, the actual compact and full catalogs exposed it. This is a concrete discoverability requirement, not an agent-selection experiment. The scratch implementation remains uncommitted: naming, the absent-versus-unsupported declaration, per-invocation freshness receipt, linking original failure Evidence, concurrent ownership, CLI snapshot and batch semantics, and interaction with #8786's grouped capability change remain unresolved. It is not ready for integration.

Snapshot and concurrent-cancellation prototype controls

With the uncommitted prototype and real Kuna 1.989 on macOS arm64, two separate CLI decompile --analysis independent_fresh --snapshot <same path> invocations both launched a standalone decompile, as counted by a test-only wrapper. Their identical outputs had the same Evidence ID; the request parameter and single-function source remained in each result. This validates the tested Kuna live-cache route with one saved snapshot; it does not establish that every future provider's pre-open snapshot replay path honors this selection.

A separate compact MCP control launched two independent requests using test-owned Node wrappers that waited before delegating the surviving request to real Kuna. Cancelling one request did not cancel the other; after releasing the survivor it returned pseudocode, close_binary succeeded, and both wrapper PIDs were stopped. This deliberately controlled process test covers one interleaving; slot saturation, simultaneous cancellation, unproven-stop retry and other hosts remain unverified. The prototype is still uncommitted and the contract/receipt and Evidence-link questions above remain open.

Repeatable MCP-boundary prototype regressions

The uncommitted prototype now has three focused SDK/MCP tests using a synthetic Kuna fixture: compact and full profiles retain the original failed project observation alongside a new standalone result, report the provider declaration, and verify that two fresh requests launch two subprocesses; a controlled unproven-stop test retains the sole run slot, prevents a queued fresh request from launching, keeps close unsuccessful until the owner resolves, and succeeds on a fresh request after reopening. All three focused tests and check:ci:fast passed. This is production session and SDK plumbing with simulated provider/cleanup behavior, not proof of real Kuna unproven-stop behavior. The prototype remains uncommitted and its previously listed contract and replay gaps remain open.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8167 ### Independent-attempt timeout and concurrency controls On the same uncommitted independent-retry prototype, a test-only wrapper ran an inspectable stalled Node process in place of the standalone decompiler, with `REA_KUNA_TIMEOUT_MS=500`. In both MCP profiles the explicit attempt returned `provider_timeout`; the original completed-project observation remained null, and after removing the stall a later explicit fresh Kuna attempt returned pseudocode. Both the original and later successful Evidence records were retained. The timeout error itself was not shown to become an Evidence record. The target SHA-256 `0e0ecf82c96e4918ee2ca1287dc25513d8fd13d5ab7fa5b98db00ad342f03930` remained unchanged and the target was not run. A separate compact-profile control issued two concurrent fresh requests for the same function. The test wrapper recorded two standalone decompile launches; both succeeded and produced the same content-addressed Evidence ID. This is the prototype's current behavior, not a chosen concurrency contract: coalescing, explicit run receipts, admission bounds and cancellation of one versus both callers still require design and verification. Neither test establishes real Kuna timeout behavior or cross-platform cleanup. ### Prototype discovery and CLI controls The isolated prototype was extended to project its provider declaration through grouped `binary_session` capabilities and to expose the selection on the existing `rea decompile` command. With real Kuna 1.989 and Ghidra 12.1.4 in both MCP schema profiles, summary and complete status reported the declaration for Kuna's pseudocode operation and omitted it for Ghidra; the explicit request succeeded with Kuna and was refused with Ghidra. The SDK-advertised input and output schemas validated and successful status/results matched them. On the warm mixed-failure cache, real CLI `decompile --analysis independent_fresh` returned the standalone body and its context limitation; the ordinary CLI command returned the project's null body and worker-failure limitation. The first discovery version put guidance only in the input field description. The compact schema omitted that description, so the tool description did not explain the choice there. After adding the guidance to the tool description, the actual compact and full catalogs exposed it. This is a concrete discoverability requirement, not an agent-selection experiment. The scratch implementation remains uncommitted: naming, the absent-versus-unsupported declaration, per-invocation freshness receipt, linking original failure Evidence, concurrent ownership, CLI snapshot and batch semantics, and interaction with #8786's grouped capability change remain unresolved. It is not ready for integration. ### Snapshot and concurrent-cancellation prototype controls With the uncommitted prototype and real Kuna 1.989 on macOS arm64, two separate CLI `decompile --analysis independent_fresh --snapshot <same path>` invocations both launched a standalone decompile, as counted by a test-only wrapper. Their identical outputs had the same Evidence ID; the request parameter and single-function source remained in each result. This validates the tested Kuna live-cache route with one saved snapshot; it does not establish that every future provider's pre-open snapshot replay path honors this selection. A separate compact MCP control launched two independent requests using test-owned Node wrappers that waited before delegating the surviving request to real Kuna. Cancelling one request did not cancel the other; after releasing the survivor it returned pseudocode, `close_binary` succeeded, and both wrapper PIDs were stopped. This deliberately controlled process test covers one interleaving; slot saturation, simultaneous cancellation, unproven-stop retry and other hosts remain unverified. The prototype is still uncommitted and the contract/receipt and Evidence-link questions above remain open. ### Repeatable MCP-boundary prototype regressions The uncommitted prototype now has three focused SDK/MCP tests using a synthetic Kuna fixture: compact and full profiles retain the original failed project observation alongside a new standalone result, report the provider declaration, and verify that two fresh requests launch two subprocesses; a controlled unproven-stop test retains the sole run slot, prevents a queued fresh request from launching, keeps close unsuccessful until the owner resolves, and succeeds on a fresh request after reopening. All three focused tests and `check:ci:fast` passed. This is production session and SDK plumbing with simulated provider/cleanup behavior, not proof of real Kuna unproven-stop behavior. The prototype remains uncommitted and its previously listed contract and replay gaps remain open.

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:52:32 +00:00

bsakaguchi referenced this issue

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

[PR #4699] [CLOSED] fix(kuna): resolve retained process failures once their owner releases #6364

bsakaguchi added

enhancement

and removed

enhancement

labels

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

bsakaguchi commented

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

Author

Owner

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

A controlled Kuna 1.986 follow-up exercised warm-cache recovery across fresh MCP servers. A caller-owned test wrapper conditionally injected the upstream test-only worker stall at 0x100000410 with a one-second watchdog for decompile-project; it logged command invocations. This wrapper and its marker file are test instrumentation, not a normal release configuration or evidence of natural timeout frequency.

With the marker present, REA/Kuna jobs 2 created a completed mixed export with two decompiled functions and one failed function. procedure_pseudo_code returned null with the worker-stall limitation.
I removed only the owned marker, then opened a new MCP server with the same wrapper, binary, jobs and cache directory. The wrapper log showed version probes but no new functions or decompile-project invocation. REA again returned null with the retained stall limitation: the verified partial export was reused even though the injected failure was no longer active.
A third server with the same wrapper and a separate empty cache ran a fresh project export, recorded three successes and zero failures, and returned _adjust pseudocode. Direct unwrapped Kuna 1.986 single-function decompilation also returned that body. The clean cache and partial cache manifests had the same export key in separate directories. Both represent this controlled fixture; no elapsed-time or correctness ranking is claimed.

The target digest was unchanged. An initial attempted injection using a custom environment variable did not take effect in the provider child; it produced a successful export and is excluded from the reproduction. The marker-driven second harness above demonstrated the actual stall and per-run invocation sequence. This confirms that a completed partial export can persist across server restarts and that a manually selected fresh cache can recover the function, without implying that an agent should delete caches or that a different cache provides an equivalent whole-program interpretation automatically.

@morluto commented on GitHub (Oct 30, 2026): A controlled Kuna 1.986 follow-up exercised warm-cache recovery across fresh MCP servers. A caller-owned test wrapper conditionally injected the upstream test-only worker stall at `0x100000410` with a one-second watchdog for `decompile-project`; it logged command invocations. This wrapper and its marker file are test instrumentation, not a normal release configuration or evidence of natural timeout frequency. 1. With the marker present, REA/Kuna jobs 2 created a completed mixed export with two decompiled functions and one failed function. `procedure_pseudo_code` returned null with the worker-stall limitation. 2. I removed only the owned marker, then opened a new MCP server with the same wrapper, binary, jobs and cache directory. The wrapper log showed version probes but no new `functions` or `decompile-project` invocation. REA again returned null with the retained stall limitation: the verified partial export was reused even though the injected failure was no longer active. 3. A third server with the same wrapper and a separate empty cache ran a fresh project export, recorded three successes and zero failures, and returned `_adjust` pseudocode. Direct unwrapped Kuna 1.986 single-function decompilation also returned that body. The clean cache and partial cache manifests had the same export key in separate directories. Both represent this controlled fixture; no elapsed-time or correctness ranking is claimed. The target digest was unchanged. An initial attempted injection using a custom environment variable did not take effect in the provider child; it produced a successful export and is excluded from the reproduction. The marker-driven second harness above demonstrated the actual stall and per-run invocation sequence. This confirms that a completed partial export can persist across server restarts and that a manually selected fresh cache can recover the function, without implying that an agent should delete caches or that a different cache provides an equivalent whole-program interpretation automatically.

bsakaguchi commented

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

Author

Owner

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

A further real MCP check exercised decompile_all recovery using the two isolated 1.986 cache contexts from the controlled reproduction above. I selected only the affected address and used a new owned output directory:

Against the partial export, decompile_all reported one no_pseudocode failure. The index and journal retained the provider's worker-stall limitation, and the top-level Evidence also included it.
A fresh server using the same partial cache and resume: true retried the recorded failed function and reported the same failure; the journal appended another failed record.
Another fresh server using the previously built successful cache resumed the same target/provider/profile/layout journal, wrote one function file and reported zero failures. Its derived index now described the function as written; the append-only journal retained both previous failures and the successful record. The earlier failure Evidence bundles had also been explicitly exported before session close.

This shows that REA's export resume can recover a failed function once its provider supplies a result; retrying the same cached partial provider project does not itself produce one. The test selected one function only, so it does not establish handling of unrelated existing files or broader concurrency. The changed cache location was deliberate test configuration, not a recommendation to delete or mutate an existing cache. The source binary SHA-256 stayed unchanged. The stall was injected test instrumentation; no natural timeout frequency is claimed.

@morluto commented on GitHub (Oct 30, 2026): A further real MCP check exercised `decompile_all` recovery using the two isolated 1.986 cache contexts from the controlled reproduction above. I selected only the affected address and used a new owned output directory: 1. Against the partial export, `decompile_all` reported one `no_pseudocode` failure. The index and journal retained the provider's worker-stall limitation, and the top-level Evidence also included it. 2. A fresh server using the same partial cache and `resume: true` retried the recorded failed function and reported the same failure; the journal appended another failed record. 3. Another fresh server using the previously built successful cache resumed the same target/provider/profile/layout journal, wrote one function file and reported zero failures. Its derived index now described the function as written; the append-only journal retained both previous failures and the successful record. The earlier failure Evidence bundles had also been explicitly exported before session close. This shows that REA's export resume can recover a failed function once its provider supplies a result; retrying the same cached partial provider project does not itself produce one. The test selected one function only, so it does not establish handling of unrelated existing files or broader concurrency. The changed cache location was deliberate test configuration, not a recommendation to delete or mutate an existing cache. The source binary SHA-256 stayed unchanged. The stall was injected test instrumentation; no natural timeout frequency is claimed.

bsakaguchi commented

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

Author

Owner

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

A related mixed-batch follow-up using the same deliberately injected 1.986 partial cache exposed a separate result-projection problem: the failed function's item was unreadable_output with doctor advice and provider returned empty pseudocode, while the watchdog failure remained only in the batch-wide limitations. A batch-only exported Evidence bundle contained the batch record and no per-function records or links; a separate procedure_pseudo_code call associated the watchdog limitation with the selected function. The successful function and invalid selector remained distinguishable and counts were correct. This does not establish a natural stall or automatic recovery.

Filed #8226 for retaining per-item provider-failure association; this issue remains about retrying the failed cached provider result. The target SHA-256 stayed unchanged.

@morluto commented on GitHub (Oct 30, 2026): A related mixed-batch follow-up using the same deliberately injected 1.986 partial cache exposed a separate result-projection problem: the failed function's item was `unreadable_output` with doctor advice and `provider returned empty pseudocode`, while the watchdog failure remained only in the batch-wide limitations. A batch-only exported Evidence bundle contained the batch record and no per-function records or links; a separate `procedure_pseudo_code` call associated the watchdog limitation with the selected function. The successful function and invalid selector remained distinguishable and counts were correct. This does not establish a natural stall or automatic recovery. Filed #8226 for retaining per-item provider-failure association; this issue remains about retrying the failed cached provider result. The target SHA-256 stayed unchanged.

bsakaguchi commented

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

Author

Owner

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

A real two-function MCP resume control checks the earlier one-function result without losing an already successful output. Using the same intentionally stalled 1.986 partial export and independently completed clean cache:

Initial partial export selected _adjust and _evaluate: one failed and one was written.
Resuming against the same partial cache retried only _adjust, left _evaluate skipped with the same output-file SHA-256, and failed again.
Resuming against the clean cache retried only _adjust, wrote it successfully, and again left _evaluate's file digest unchanged. The journal retained both failures and the success; the final index recorded both written files.

Separate procedure_pseudo_code calls for the successful _evaluate returned identical text in both cache contexts, but their source project-export file digests differed. No general equivalence claim follows. The executable was unchanged and not executed; this uses a deliberately injected test stall, not a measured natural failure.

The directory index and separately exported composed workflow Evidence do not retain the exact per-file project-export source in this control; #8260 tracks that separate provenance question. This does not change the fact that the journal retained output digests, per-function limitations and attempt history.

@morluto commented on GitHub (Oct 31, 2026): A real two-function MCP resume control checks the earlier one-function result without losing an already successful output. Using the same intentionally stalled 1.986 partial export and independently completed clean cache: - Initial partial export selected `_adjust` and `_evaluate`: one failed and one was written. - Resuming against the same partial cache retried only `_adjust`, left `_evaluate` skipped with the same output-file SHA-256, and failed again. - Resuming against the clean cache retried only `_adjust`, wrote it successfully, and again left `_evaluate`'s file digest unchanged. The journal retained both failures and the success; the final index recorded both written files. Separate `procedure_pseudo_code` calls for the successful `_evaluate` returned identical text in both cache contexts, but their source project-export file digests differed. No general equivalence claim follows. The executable was unchanged and not executed; this uses a deliberately injected test stall, not a measured natural failure. The directory index and separately exported composed workflow Evidence do not retain the exact per-file project-export source in this control; [#8260](https://github.com/morluto/rea/issues/8260) tracks that separate provenance question. This does not change the fact that the journal retained output digests, per-function limitations and attempt history.

bsakaguchi commented

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

Author

Owner

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

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

bsakaguchi commented

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

Author

Owner

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

CLI mixed-result and resume control

I repeated the two-function recovery through the public rea decompile-all CLI on REA b43c329df779708e43ae297f498a844e45d9c923 and Kuna 1.986, using the previously prepared isolated partial and clean caches. The partial cache was produced with the same deliberately injected one-second worker stall described above; this does not establish a naturally occurring timeout.

With a new output directory and the two entry addresses selected, the initial CLI call exited 0 with written: 1, failed: 1; the index associated the failed entry with the worker-stall limitation and the complete CLI Evidence also included that limitation. Resuming against the same partial cache exited 0 with skipped: 1, failed: 1; the existing successful file's SHA-256 was unchanged. Resuming with the separately prepared clean cache exited 0 with skipped: 1, written: 1, failed: 0; the earlier successful file's digest was still unchanged. The append-only journal contained both failure attempts and the later success.

This confirms the documented partial-result/resume behavior through the CLI as well as MCP. A zero exit reflects a completed export operation, so a caller must inspect the manifest counts; it does not mean every selected function was decompiled. The clean cache was deliberate test setup, not a general instruction to delete existing cache state or a claim that independently produced exports are equivalent. The target remained unchanged and was not executed. Exact per-file producer provenance across these cache contexts remains #8260.

@morluto commented on GitHub (Oct 31, 2026): ### CLI mixed-result and resume control I repeated the two-function recovery through the public `rea decompile-all` CLI on REA `b43c329df779708e43ae297f498a844e45d9c923` and Kuna 1.986, using the previously prepared isolated partial and clean caches. The partial cache was produced with the same deliberately injected one-second worker stall described above; this does not establish a naturally occurring timeout. With a new output directory and the two entry addresses selected, the initial CLI call exited 0 with `written: 1`, `failed: 1`; the index associated the failed entry with the worker-stall limitation and the complete CLI Evidence also included that limitation. Resuming against the same partial cache exited 0 with `skipped: 1`, `failed: 1`; the existing successful file's SHA-256 was unchanged. Resuming with the separately prepared clean cache exited 0 with `skipped: 1`, `written: 1`, `failed: 0`; the earlier successful file's digest was still unchanged. The append-only journal contained both failure attempts and the later success. This confirms the documented partial-result/resume behavior through the CLI as well as MCP. A zero exit reflects a completed export operation, so a caller must inspect the manifest counts; it does not mean every selected function was decompiled. The clean cache was deliberate test setup, not a general instruction to delete existing cache state or a claim that independently produced exports are equivalent. The target remained unchanged and was not executed. Exact per-file producer provenance across these cache contexts remains #8260.

bsakaguchi commented

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

Author

Owner

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

Snapshot and comparison after explicit clean-cache selection

On REA a989c0e with Kuna 1.986, I copied the previously documented deliberately stalled and clean cache trees into separate disposable directories. Using the same caller-owned launcher and target, the partial-cache session returned null pseudocode for _adjust, with the injected 1-second watchdog reason. Its complete function dossier had pseudocode unavailable and retained that reason. close_binary(snapshot_path) saved two Evidence records and no primitive/workflow cache entries.

A fresh server explicitly configured with the clean cache reopened that snapshot. The historical dossier's pseudocode view still reported the original failure, while a new pseudocode request and dossier returned the real body. The same export key referred to different source export file digests; this check does not mean every partial export can be recovered by changing cache directories or that REA automatically retries it. Target and saved snapshot hashes remained unchanged; the target was not executed.

Comparing the retained failed dossier to the new successful dossier yielded pseudocode unknown with the watchdog reason, not an inferred code change. The exact assembly text dimension was changed because the clean export added two ; arg/; stack metadata lines; the eight instruction rows were identical in this fixture. In a fresh target-free server, find_changed_behavior on the retained comparison returned one assembly static candidate, zero observed changes and overall behavior unknown, retaining its warning that text/layout differences do not establish behavioral change. This is a useful limit on interpreting the candidate, not a claim that the comparison made a behavioral verdict. It also shows why a future retry should preserve both historical and replacement Evidence rather than silently rewriting the failed record.

@morluto commented on GitHub (Oct 31, 2026): ### Snapshot and comparison after explicit clean-cache selection On REA `a989c0e` with Kuna 1.986, I copied the previously documented deliberately stalled and clean cache trees into separate disposable directories. Using the same caller-owned launcher and target, the partial-cache session returned null pseudocode for `_adjust`, with the injected 1-second watchdog reason. Its complete function dossier had pseudocode unavailable and retained that reason. `close_binary(snapshot_path)` saved two Evidence records and no primitive/workflow cache entries. A fresh server explicitly configured with the clean cache reopened that snapshot. The historical dossier's pseudocode view still reported the original failure, while a new pseudocode request and dossier returned the real body. The same export key referred to different source export file digests; this check does not mean every partial export can be recovered by changing cache directories or that REA automatically retries it. Target and saved snapshot hashes remained unchanged; the target was not executed. Comparing the retained failed dossier to the new successful dossier yielded pseudocode `unknown` with the watchdog reason, not an inferred code change. The exact **assembly text** dimension was `changed` because the clean export added two `; arg`/`; stack` metadata lines; the eight instruction rows were identical in this fixture. In a fresh target-free server, `find_changed_behavior` on the retained comparison returned one assembly static candidate, zero observed changes and overall behavior `unknown`, retaining its warning that text/layout differences do not establish behavioral change. This is a useful limit on interpreting the candidate, not a claim that the comparison made a behavioral verdict. It also shows why a future retry should preserve both historical and replacement Evidence rather than silently rewriting the failed record.

bsakaguchi commented

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

Author

Owner

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

A current-main batch recovery observation after #8323: on REA 2d5dec26c31662764c9adfe3ff996174901b8d49 / real Kuna 1.986, the previously prepared test-only stalled export now associates the watchdog caveat with the failed batch item. The item has structured code: capability_unavailable, category: unsupported_provider, retryable: false, and reason: provider returned null pseudocode; binary_session reports procedure_pseudo_code available. In a separate server with the explicitly selected clean cache, the same provider and target returned that function's body. The original failed record remains intact offline.

This does not mean the operation is globally unsupported: the capability report describes the operation, while the batch error describes this item. It raises an agent-UX question for recovery: can a caller distinguish an item with a provider-reported processing failure from an entry that has no analyzable body without interpreting provider prose? The current source observation is null plus caveats, so a repair must preserve the provider's actual facts and avoid inventing a typed timeout by parsing text. The clean-cache control is explicit test setup, not a recommendation to clear or silently replace a cache. The stall was injected and no target executed.

@morluto commented on GitHub (Oct 31, 2026): A current-main batch recovery observation after #8323: on REA `2d5dec26c31662764c9adfe3ff996174901b8d49` / real Kuna 1.986, the previously prepared test-only stalled export now associates the watchdog caveat with the failed batch item. The item has structured `code: capability_unavailable`, `category: unsupported_provider`, `retryable: false`, and `reason: provider returned null pseudocode`; `binary_session` reports `procedure_pseudo_code` available. In a separate server with the explicitly selected clean cache, the same provider and target returned that function's body. The original failed record remains intact offline. This does not mean the operation is globally unsupported: the capability report describes the operation, while the batch error describes this item. It raises an agent-UX question for recovery: can a caller distinguish an item with a provider-reported processing failure from an entry that has no analyzable body without interpreting provider prose? The current source observation is null plus caveats, so a repair must preserve the provider's actual facts and avoid inventing a typed timeout by parsing text. The clean-cache control is explicit test setup, not a recommendation to clear or silently replace a cache. The stall was injected and no target executed.

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-11-03 06:15:59 +00:00

bsakaguchi commented

2026-11-03 15:31:07 +00:00

Author

Owner

@morluto commented on GitHub (Nov 3, 2026):

Combined-control follow-up on the draft independent retry (#8793) and directory-source facts (#8805): I applied both branches in a disposable checkout and exercised real Kuna 1.989 through compact and full MCP profiles on macOS arm64. The two branches applied cleanly except for a test-only conflict where both append snapshot regressions; I retained both. Focused combined tests: 35 passed, 2 skipped.

With a test-only injected worker panic in a two-function project export, the original pseudocode was null. An explicit independent_fresh request returned text and both observations remained in the Evidence bundle; a later ordinary pseudocode request still returned the project's null. Calling decompile_all against that same partial project wrote the other function and recorded this one as failed, including the partial project's source digest. After opening a fresh server against a separately built clean cache, resume retained the first output and its original source, then wrote the failed function with the clean project's different source digest. The earlier failed source remained in the journal. The target and retained file digests were unchanged; no target was executed.

This confirms an intentional current limitation of the drafts: a successful independent observation is not automatically substituted into decompile_all, so a caller cannot use that observation to complete the same partial-cache export through the existing directory workflow. Whether a directory export should accept explicit per-function sources or a retry policy is a separate design question; any solution must preserve provenance and avoid silently treating standalone and project contexts as equivalent. The injected failure does not establish natural frequency.

@morluto commented on GitHub (Nov 3, 2026): Combined-control follow-up on the draft independent retry (#8793) and directory-source facts (#8805): I applied both branches in a disposable checkout and exercised real Kuna 1.989 through compact and full MCP profiles on macOS arm64. The two branches applied cleanly except for a test-only conflict where both append snapshot regressions; I retained both. Focused combined tests: 35 passed, 2 skipped. With a test-only injected worker panic in a two-function project export, the original pseudocode was null. An explicit `independent_fresh` request returned text and both observations remained in the Evidence bundle; a later ordinary pseudocode request still returned the project's null. Calling `decompile_all` against that same partial project wrote the other function and recorded this one as failed, including the partial project's source digest. After opening a fresh server against a separately built clean cache, resume retained the first output and its original source, then wrote the failed function with the clean project's different source digest. The earlier failed source remained in the journal. The target and retained file digests were unchanged; no target was executed. This confirms an intentional current limitation of the drafts: a successful independent observation is not automatically substituted into `decompile_all`, so a caller cannot use that observation to complete the same partial-cache export through the existing directory workflow. Whether a directory export should accept explicit per-function sources or a retry policy is a separate design question; any solution must preserve provenance and avoid silently treating standalone and project contexts as equivalent. The injected failure does not establish natural frequency.

bsakaguchi commented

2026-11-03 15:31:07 +00:00

Author

Owner

@morluto commented on GitHub (Nov 3, 2026):

A real Kuna 1.989 import-slot control narrows how a future directory retry policy should choose work. On macOS arm64, I compiled an owned Mach-O that calls puts (the target was not run). Kuna's inventory listed both the code stub at 0x1000004ac and the loader-written slot at 0x100004000 under puts.

Through the combined #8793/#8805 MCP prototype after project export, procedure_pseudo_code(0x100004000) returned null with the provider limitation that this inventory entry has no body. An explicit independent attempt for that slot returned execution_failure; direct Kuna also refused the selector, explaining that the import slot holds a loader-written pointer rather than a function body. By contrast, both ordinary and independent pseudocode requests for the code stub returned text. The target hash remained unchanged.

This is a distinct observed reason for null from the injected worker-failure case: an automatic retry of every null would also launch an unnecessary, failing standalone decompile for a no-body entry. A possible opt-in directory recovery therefore needs a provider-owned distinction between an actual failed function and an entry with no body, rather than matching prose or treating all nulls as retryable. The prototype does not yet provide such a typed distinction. One fixture, one Kuna version and one host were tested; this does not establish a natural failure rate.

Correction after inspecting the project reader: absence of a block proves only that the entry is not in the export. It does not prove every omitted inventory entry has no body. The direct Kuna refusal independently identifies this specific import slot as bodyless; a general typed result should preserve not-in-export as unknown rather than label all omissions no-body.

@morluto commented on GitHub (Nov 3, 2026): A real Kuna 1.989 import-slot control narrows how a future directory retry policy should choose work. On macOS arm64, I compiled an owned Mach-O that calls `puts` (the target was not run). Kuna's inventory listed both the code stub at `0x1000004ac` and the loader-written slot at `0x100004000` under `puts`. Through the combined #8793/#8805 MCP prototype after project export, `procedure_pseudo_code(0x100004000)` returned null with the provider limitation that this inventory entry has no body. An explicit independent attempt for that slot returned `execution_failure`; direct Kuna also refused the selector, explaining that the import slot holds a loader-written pointer rather than a function body. By contrast, both ordinary and independent pseudocode requests for the code stub returned text. The target hash remained unchanged. This is a distinct observed reason for null from the injected worker-failure case: an automatic retry of every null would also launch an unnecessary, failing standalone decompile for a no-body entry. A possible opt-in directory recovery therefore needs a provider-owned distinction between an actual failed function and an entry with no body, rather than matching prose or treating all nulls as retryable. The prototype does not yet provide such a typed distinction. One fixture, one Kuna version and one host were tested; this does not establish a natural failure rate. Correction after inspecting the project reader: absence of a block proves only that the entry is not in the export. It does not prove every omitted inventory entry has no body. The direct Kuna refusal independently identifies this specific import slot as bodyless; a general typed result should preserve `not-in-export` as unknown rather than label all omissions `no-body`.

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

No description provided.

Rows
Columns