morluto/rea

Fork 0

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

[GH-ISSUE #8212] [Design] Define Kuna cache publication when a session is cancelled #6488

New issue

Open

opened 2026-11-01 21:11:34 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

What should callers be told when closing a Kuna session cancels an export after verification has completed but while publication is awaiting its atomic rename? Should a verified cache entry be allowed to publish, or should a cancellation observed before the rename prevent publication? Either choice needs a clear commit boundary and cleanup semantics.

Context and evidence

The Kuna guide says closing the session cancels its background export unless another session waits. In a controlled real MCP stdio run on macOS arm64, REA branch 38433cfb4577b133d7598f9439c6448299cb44eb used real Kuna 1.986 on a self-built Mach-O. An audit-only Node preload intercepted the production rename from a verified staged entry into projects/<key> and held it before invoking the filesystem rename. This was synchronization instrumentation; the normal REA and Kuna code performed the analysis and publication.

While the rename was held, I cancelled the sole procedure_assembly waiter and invoked close_binary. An instrumented abort marker confirmed KunaSessionClient.close aborted its session before the barrier was released. Before release, the project directory was absent and staging was present. After release, the client saw cancellation for the waiter, close_binary succeeded, binary_session said open: false and cleanup_pending: false, staging was empty, and the cache entry existed. The target digest was unchanged.

I independently verified the five published file sizes and SHA-256 values against the manifest. A fresh MCP server returned assembly and pseudocode from that export key, with the same manifest inode and modification time. A non-cancelled control using the same barrier also succeeded. The first attempt at this harness did not reach the barrier because the test matched /tmp instead of its /private/tmp canonical path; that failed attempt is not part of the result.

This is a single synchronized experiment, not a claim of natural frequency, corruption, or a security issue. The cache is REA-owned; no user-selected output artifact or target executable was changed. The visible cancellation is the MCP client's abort, not a structured server error. Other cancellation windows, failures during the rename or final cleanup, other hosts, and the intended contract remain unknown.

Expected interaction with targets

Read the selected binary; launch the caller-supplied Kuna executable; write only REA's owned cache and staging. No target execution is proposed.

Boundary details (optional)

Preserve target and provider identity, only expose complete validated exports, avoid deleting unproven live staging, and distinguish a cancelled caller from a shared session-owned producer. A published entry after cancellation can be valid but should not be described as an export that definitely never committed. Preserve cleanup failure and any already-published receipt separately.

Options and tradeoffs

Document that an in-progress publication can finish after cancellation and remains reusable; or check cancellation immediately before admission to publication and define the point after which atomic commit wins. A precheck cannot undo a rename already issued. Do not add a new agent tool solely for this edge case without demonstrating an analyst need.

Verification available so far

I have a prototype or observed results

Success criteria and open questions

State the selected observable behavior for cancellation before, during and after publication. Verify a synchronized non-cancelled control, sole and shared waiters, cancellation during final cleanup, failure/cleanup retry and warm reopen. Clarify whether the guide's current cancellation wording includes an already-in-flight publication. No performance or broad-platform conclusion is claimed here.

References

Related: #8176 (export progress/shared waiters), #6051 (already-published export with failed staging retirement), and #4227 (lifecycle audit). The producer uses an atomic directory rename in KunaProjectCache.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8212 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed What should callers be told when closing a Kuna session cancels an export after verification has completed but while publication is awaiting its atomic rename? Should a verified cache entry be allowed to publish, or should a cancellation observed before the rename prevent publication? Either choice needs a clear commit boundary and cleanup semantics. ### Context and evidence The [Kuna guide](https://github.com/morluto/rea/blob/38433cfb4577b133d7598f9439c6448299cb44eb/docs/kuna-provider.md) says closing the session cancels its background export unless another session waits. In a controlled real MCP stdio run on macOS arm64, REA branch `38433cfb4577b133d7598f9439c6448299cb44eb` used real Kuna 1.986 on a self-built Mach-O. An audit-only Node preload intercepted the production rename from a verified staged `entry` into `projects/<key>` and held it **before** invoking the filesystem rename. This was synchronization instrumentation; the normal REA and Kuna code performed the analysis and publication. While the rename was held, I cancelled the sole `procedure_assembly` waiter and invoked `close_binary`. An instrumented abort marker confirmed `KunaSessionClient.close` aborted its session before the barrier was released. Before release, the project directory was absent and staging was present. After release, the client saw cancellation for the waiter, `close_binary` succeeded, `binary_session` said `open: false` and `cleanup_pending: false`, staging was empty, and the cache entry existed. The target digest was unchanged. I independently verified the five published file sizes and SHA-256 values against the manifest. A fresh MCP server returned assembly and pseudocode from that export key, with the same manifest inode and modification time. A non-cancelled control using the same barrier also succeeded. The first attempt at this harness did not reach the barrier because the test matched `/tmp` instead of its `/private/tmp` canonical path; that failed attempt is not part of the result. This is a single synchronized experiment, not a claim of natural frequency, corruption, or a security issue. The cache is REA-owned; no user-selected output artifact or target executable was changed. The visible cancellation is the MCP client's abort, not a structured server error. Other cancellation windows, failures during the rename or final cleanup, other hosts, and the intended contract remain unknown. ### Expected interaction with targets Read the selected binary; launch the caller-supplied Kuna executable; write only REA's owned cache and staging. No target execution is proposed. ### Boundary details (optional) Preserve target and provider identity, only expose complete validated exports, avoid deleting unproven live staging, and distinguish a cancelled caller from a shared session-owned producer. A published entry after cancellation can be valid but should not be described as an export that definitely never committed. Preserve cleanup failure and any already-published receipt separately. ### Options and tradeoffs Document that an in-progress publication can finish after cancellation and remains reusable; or check cancellation immediately before admission to publication and define the point after which atomic commit wins. A precheck cannot undo a rename already issued. Do not add a new agent tool solely for this edge case without demonstrating an analyst need. ### Verification available so far I have a prototype or observed results ### Success criteria and open questions State the selected observable behavior for cancellation before, during and after publication. Verify a synchronized non-cancelled control, sole and shared waiters, cancellation during final cleanup, failure/cleanup retry and warm reopen. Clarify whether the guide's current cancellation wording includes an already-in-flight publication. No performance or broad-platform conclusion is claimed here. ### References Related: #8176 (export progress/shared waiters), #6051 (already-published export with failed staging retirement), and #4227 (lifecycle audit). The producer uses an atomic directory rename in [`KunaProjectCache`](https://github.com/morluto/rea/blob/38433cfb4577b133d7598f9439c6448299cb44eb/src/kuna/KunaProjectCache.ts).

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

2026-11-01 21:11:35 +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.

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

No description provided.

Rows
Columns