fix(kuna): list a cold target from the export's own inventory (#4062)

* fix(kuna): list a cold target from the export's own inventory On a cold cache the session ran `kuna functions --json` for listings while the background export ran the same inventory as its first step, so every cold target was inventoried twice at once. On a 254 MB Mach-O each run took about 66 s of CPU. The quick run was also bound by the single-function deadline. The export's status now carries its parsed inventory, the cache replays the latest status to requests that join a running build, and listings wait for that inventory. The session runs its own inventory only when the export ends without one. Refs #1957 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(kuna): replay a running build's status after its waiter can cancel The cache replayed the latest status to a joining request before it registered that request's abort listener, so a listener that cancelled on the replayed status was ignored and the request waited for the export to finish. Replay now happens once cancellation is registered. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * perf(kuna): publish the export's inventory without parsing it twice The export parsed `functions.json` for its status and then parsed the file it had just written again to publish, so two expanded inventories coexisted while the export finished. Publishing now reuses the inventory parsed from that same text. Cached lookups still parse the published file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(kuna): exercise export inventory sharing from pseudocode requests Inventory-only requests no longer start the export, so a cold request that shares the export's inventory is now a text request. The tests and the guide describe that trigger. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(kuna): let a listing wait for an export that is still starting A listing that arrived while a concurrent text request was still looking up the cache saw no export inventory yet and started its own `kuna functions`, and the export then started another. The listing now waits for that startup decision before falling back to its own run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-26 17:35:11 +00:00 · 2026-10-15 05:19:25 -07:00
1 parent 2b5ee72d26
commit 8ed3d1df72
@@ -19,7 +19,7 @@ Select it explicitly with `--provider kuna`, MCP's `open_binary.provider_id: "ku
 | `REA_KUNA_CACHE_DIR`          | `~/Library/Caches/rea/kuna` (macOS), `$XDG_CACHE_HOME/rea/kuna` (Linux; `~/.cache/rea/kuna` when `XDG_CACHE_HOME` is unset or relative) | Absolute directory REA owns for project exports. Kuna's own spec cache also lives here, not in your Kuna cache.                                                                          |
 | `REA_KUNA_CACHE_MAX_BYTES`    | 4 GiB                                                                                                                                   | Size cap; least recently used exports are evicted above it.                                                                                                                              |
 | `REA_KUNA_PROJECT_TIMEOUT_MS` | 30 minutes                                                                                                                              | Deadline for one project export.                                                                                                                                                         |
-| `REA_KUNA_TIMEOUT_MS`         | 120 s                                                                                                                                   | Deadline for one single-function decompile.                                                                                                                                              |
+| `REA_KUNA_TIMEOUT_MS`         | 120 s                                                                                                                                   | Deadline for one single-function decompile, and for the inventory run REA makes when the export ends without one.                                                                        |
 | `REA_KUNA_JOBS`               | 1                                                                                                                                       | `decompile-project --jobs`. 1 is Kuna's reference answer; more jobs finish sooner but lose callee-first prototypes, and change about 40–60% of function bodies on the measured binaries. |

 Windows is not supported yet. Supported targets are ELF and thin Mach-O executables for x86-64, AArch64 and ARM; PE and universal Mach-O are rejected with a typed reason.
@@ -45,7 +45,7 @@ The first text or assembly request in a session looks for this target's export i
 - **Warm cache:** analysis reads reuse the verified export. A fresh server verifies its file digests once, even for concurrent first requests; that cost scales with export size.
 - **Cold cache:**
  - REA starts `kuna decompile-project` in the background on a private copy of the target.
-  - Meanwhile, pseudocode comes from one `kuna decompile --addr` run, and listings from `kuna functions --json`.
+  - Meanwhile, pseudocode comes from one `kuna decompile --addr` run. Name and address lookups, and listings, use the inventory the export takes with `kuna functions --json` before it decompiles. The session runs `kuna functions` itself, under `REA_KUNA_TIMEOUT_MS`, only when no export is building (an inventory-only request does not start one) or the export ends without an inventory.
  - Requests for the same function share one run; it stops when its last waiting request is cancelled. Each run analyzes the whole image again in its own process, so one REA process runs at most as many at once as the host has cores beyond `REA_KUNA_JOBS` (at least one). Further requests wait in order, and a waiting request is answered from the export if it finishes first. A run whose stop REA cannot prove keeps its slot until `close_binary` proves it stopped.
  - Assembly and data names wait for the export; progress notifications report the wait every ten seconds.
  - A single-function answer says so in its limitations. It lacks the export's whole-program prototypes, so a later request can return different text for the same function.