akm-cli 0.9.0 → 0.9.1-beta.2

package/dist/workflows/exec/unit-dispatch.js

@@ -1,4 +1,34 @@
 // This Source Code Form is subject to the terms of the Mozilla Public
 // License, v. 2.0. If a copy of the MPL was not distributed with this
 // file, You can obtain one at https://mozilla.org/MPL/2.0/.
-export {};
+import { deepMergeConfig } from "../../core/config/deep-merge.js";
+import { resolveCredentialFromEnv } from "../../integrations/agent/engine-resolution.js";
+/**
+ * Materialize a frozen llm engine snapshot into a live connection: resolve the
+ * credential out of `process.env`, then apply the invocation's model/llm
+ * overrides. The ONE definition — the default dispatcher's llm runner and the
+ * frozen gate judge both dispatch through it, so credential resolution and
+ * connection-field mapping cannot drift between the two llm dispatch paths.
+ *
+ * The credential read itself is {@link resolveCredentialFromEnv}, shared with
+ * the live-config dispatch boundary (`materializeLlmConnection`): a frozen
+ * snapshot's `credential` and a resolved engine's `CredentialDescriptor` are the
+ * same descriptor, so lookup order and the "required … is not set" failure are
+ * one implementation, not two that happen to agree.
+ */
+export function materializeFrozenLlm(snapshot, invocation) {
+    const apiKey = resolveCredentialFromEnv(snapshot.credential);
+    const base = {
+        provider: snapshot.provider,
+        endpoint: snapshot.endpoint,
+        model: invocation?.model ?? snapshot.model,
+        ...(snapshot.temperature !== undefined ? { temperature: snapshot.temperature } : {}),
+        ...(snapshot.maxTokens !== undefined ? { maxTokens: snapshot.maxTokens } : {}),
+        ...(snapshot.supportsJsonSchema !== undefined ? { supportsJsonSchema: snapshot.supportsJsonSchema } : {}),
+        ...(snapshot.extraParams ? { extraParams: snapshot.extraParams } : {}),
+        ...(snapshot.contextLength !== undefined ? { contextLength: snapshot.contextLength } : {}),
+        ...(snapshot.enableThinking !== undefined ? { enableThinking: snapshot.enableThinking } : {}),
+        ...(apiKey ? { apiKey } : {}),
+    };
+    return invocation?.llm ? deepMergeConfig(base, invocation.llm) : base;
+}

package/dist/workflows/exec/unit-writer.js

@@ -5,19 +5,59 @@
  * Serialized writer queue for `workflow_run_units` (orchestration plan,
  * *Persistence changes*).
  *
- * `withWorkflowRunsRepo` opens a fresh SQLite connection per call, so N
- * parallel units completing at once would contend on SQLite's single writer
- * and burn the 30 s busy_timeout. Bun is single-threaded, so a promise-chained
- * in-process queue is sufficient: every unit write is appended to one chain
- * and executes strictly in enqueue order. Reads and gate evaluation stay OFF
- * this queue — only writes serialize.
- *
- * A failed write rejects its own caller but never wedges the chain.
+ * ## What the chain actually protects
+ *
+ * SQLite allows exactly ONE writer per database FILE. Outside a
+ * `withWorkflowRunsConnection` scope, `withWorkflowRunsRepo` opens a fresh
+ * connection per call, so N units completing at once would be N separate
+ * connections racing for the same file's write lock, burning the 30 s
+ * `busy_timeout` on contention we created ourselves. Bun runs a single-threaded
+ * event loop, so an in-process promise chain is a sufficient (and free)
+ * admission control: every unit write executes strictly in enqueue order.
+ *
+ * That is the ONLY invariant the chain owns. In particular it does NOT own
+ * per-unit insert→finish ordering: `dispatchJournaledAttempt` awaits its insert
+ * before it dispatches and only finishes after the dispatch resolves, so a
+ * unit's own writes are ordered by program order, not by queue position. The
+ * queue could be reordered arbitrarily between units without breaking
+ * `finishUnitFromDispatch`'s row-conditional logic.
+ *
+ * ## Scope of the serialization (issue B)
+ *
+ * The chain is keyed by DATABASE PATH, not global, because the resource being
+ * protected is one SQLite file's write lock. Two runs against two different
+ * data dirs (`AKM_DATA_DIR` isolation, a test sandbox, a second stash) share no
+ * write lock and must not queue behind each other. Narrowing further — per run
+ * — would be unsound: two runs in the SAME state.db still contend for that one
+ * file's writer, which is precisely what the chain exists to avoid.
+ *
+ * Inside a `withWorkflowRunsConnection` scope the chain also becomes nearly
+ * free: every write goes through the same handle, so each queued task is a
+ * synchronous statement (or a synchronous `BEGIN IMMEDIATE … COMMIT`) that
+ * settles in microseconds rather than a per-call open/migrate-preflight/close.
+ * The queue depth stops gating unit completion in practice, without weakening
+ * anything.
+ *
+ * Reads and gate evaluation stay OFF this queue — only writes serialize.
+ *
+ * A failed write rejects its own caller but never wedges its chain.
+ */
+import { serializeByKey } from "../../core/concurrent.js";
+import { getStateDbPath } from "../../core/state-db.js";
+/**
+ * One promise chain per database path ({@link serializeByKey}). Entries are
+ * pruned when their chain drains, so a long-lived process that touches many
+ * data dirs (the test harness swaps `AKM_DATA_DIR` per test) does not
+ * accumulate one resolved promise per path forever.
+ */
+const chains = new Map();
+/**
+ * Enqueue a `workflow_run_units` write behind every write already queued for
+ * the same state.db. The key is the current state.db path — the file whose one
+ * write lock this exists to protect — and is not a caller's choice: a caller
+ * writing somewhere else is not on this queue at all, and wants
+ * {@link serializeByKey} with its own chain map.
  */
-let tail = Promise.resolve();
 export function enqueueUnitWrite(fn) {
-    const run = tail.then(() => fn());
-    // Keep the chain alive regardless of individual outcomes.
-    tail = run.then(() => undefined, () => undefined);
-    return run;
+    return serializeByKey(chains, getStateDbPath(), fn);
 }