feat(graph): two-mode session deletion — the first destructive ledger operation

DELETE /api/chats/[id]?mode=preserve-graph|delete-nodes (mode required): - preserve-graph: only extraction bookkeeping dies (coverage rows, legacy checkpoints) — graph ledgers byte-untouched - delete-nodes: the chat's ledger traces die. Node survival = surviving provenance point / mapping line (notes imports carry empty provenance) / surviving event. The creator's aliases + provenance are stripped from a surviving node's create line (owner ruling 2026-09-23: name/statement/createdAt are the shared identity); orphan nodes, their edges, events, mappings, positions, embedding vectors and cluster members die; cluster labels stay (immutable) Gates: 404 unknown, 409 turn_in_flight / jobs_running (with jobIds), 503 extraction_winding_down after a 10s abort-and-poll; the purge is one sync block (ledgers → jobs → chat record last). rewriteLedgers is atomic (tmp + rename). graphRevision (max mtime over graph data files) rides the activity feed + the response as the change stamp. Anti-resurrection: the chat pipeline re-checks chat liveness at each merge — a run that slips past the wind-down aborts with nothing merged or checkpointed; its partial spend dies with the chat.
2026-09-23 02:41:04 +03:00
parent ff3700a2d0
commit a6338511d3
13 changed files with 856 additions and 5 deletions
@@ -1,11 +1,112 @@
-import { stores } from "./stores.ts";
+import { abortExtraction, extractionStatuses } from "../agent/subagents/extraction.ts";
+import { deleteChatTraces, type ChatDeleteMode, type ChatDeletionStats } from "../core/graph-deletion.ts";
 import { titleFromPrompt } from "../core/contracts.ts";
+import { graphRevision } from "./graph.ts";
+import { stores } from "./stores.ts";
+import { isTurnRunning } from "./turn-liveness.ts";

 /**
 * Server-side chat entries for the transport layer (app/api/chats*,
 * app/chat/[id]). Today these delegate straight to the ChatStore port; the
 * services stage carves the real orchestration behind this same surface.
+ *
+ * deleteChatSession (wave 6, session deletion — the FIRST destructive
+ * operation on the graph ledgers) is the one real orchestration here:
+ * gates → extraction wind-down → one synchronous deletion block. See
+ * core/graph-deletion.ts for the ledger semantics and the atomicity
+ * argument.
 */

 export const { createChat, getChat, listChats } = stores.chatStore;
 export { titleFromPrompt };
+export type { ChatDeleteMode, ChatDeletionStats } from "../core/graph-deletion.ts";
+
+/** How long the wind-down wait may take before the caller gets a retryable
+ *  503 (an aborted extraction ends at its next model-call boundary —
+ *  provider cancellation is normally sub-second, but a wedged provider
+ *  must never wedge deletion). */
+const WIND_DOWN_TIMEOUT_MS = 10_000;
+const WIND_DOWN_POLL_MS = 50;
+
+/** What deleteChatSession did — the route maps it straight to HTTP. */
+export type ChatDeleteOutcome =
+	| { ok: false; status: 404; code: "not_found"; error: string }
+	| { ok: false; status: 409; code: "turn_in_flight" | "jobs_running"; error: string; jobIds: string[] }
+	| { ok: false; status: 503; code: "extraction_winding_down"; error: string }
+	| {
+			ok: true;
+			mode: ChatDeleteMode;
+			stats: ChatDeletionStats;
+			jobsRemoved: number;
+			graphRevision: number;
+	  };
+
+/**
+ * Delete a session (owner rulings 2026-09-22/23): gates first, then the
+ * purge. The owner-locked choreography:
+ *
+ *   1. GATES — a turn in flight or a running background job refuses with
+ *      409 (they write the chat record and steer into it; deleting
+ *      mid-flight would corrupt the write-ahead flow). The UI retries once
+ *      work drains.
+ *   2. EXTRACTION WIND-DOWN — the chat's own pipeline run is TRUE-
+ *      CANCELLED (abortExtraction: spend stops, nothing merges), then
+ *      awaited off the registry. A timeout is a retryable 503, never a
+ *      forced race.
+ *   3. THE SYNC BLOCK — everything below runs without a single await:
+ *      no extraction append can interleave (the event loop never yields
+ *      mid-block), so the read-filter-write of the ledger rewrites is
+ *      atomic against the pipeline. Ledgers first, jobs next, the chat
+ *      record LAST (a crash mid-block leaves a deletable chat with a
+ *      purged graph — re-running DELETE fixes it — never a deleted chat
+ *      with live traces). The pipeline's per-batch liveness guard
+ *      (extraction.ts) closes the last window: a run that slipped past
+ *      the wind-down finds the chat gone at its merge and aborts with
+ *      nothing merged.
+ */
+export async function deleteChatSession(chatId: string, mode: ChatDeleteMode): Promise<ChatDeleteOutcome> {
+	if (!stores.chatStore.getChat(chatId)) {
+		return { ok: false, status: 404, code: "not_found", error: "No such session" };
+	}
+	if (isTurnRunning(chatId)) {
+		return {
+			ok: false,
+			status: 409,
+			code: "turn_in_flight",
+			error: "A turn is running in this session — try again when it finishes",
+			jobIds: [],
+		};
+	}
+	const runningJobs = stores.jobStore.listJobs(chatId).filter((job) => job.status === "running");
+	if (runningJobs.length > 0) {
+		return {
+			ok: false,
+			status: 409,
+			code: "jobs_running",
+			error: "Background jobs are still running in this session — try again when they finish",
+			jobIds: runningJobs.map((job) => job.id),
+		};
+	}
+	if (extractionStatuses().some((run) => run.chatId === chatId)) {
+		abortExtraction(chatId); // true cancellation — spend stops, nothing merges
+		const deadline = Date.now() + WIND_DOWN_TIMEOUT_MS;
+		while (extractionStatuses().some((run) => run.chatId === chatId)) {
+			if (Date.now() > deadline) {
+				return {
+					ok: false,
+					status: 503,
+					code: "extraction_winding_down",
+					error: "The session's extraction is still winding down — try again in a moment",
+				};
+			}
+			await new Promise((resolve) => setTimeout(resolve, WIND_DOWN_POLL_MS));
+		}
+	}
+
+	// THE SYNC BLOCK — no awaits below (see the doc comment). Order:
+	// ledgers → jobs → the chat record.
+	const stats = deleteChatTraces(stores.graphStore, chatId, mode);
+	const jobsRemoved = stores.jobStore.deleteJobsForChat(chatId);
+	stores.chatStore.deleteChat(chatId);
+	return { ok: true, mode, stats, jobsRemoved, graphRevision: graphRevision() };
+}
@@ -1,3 +1,5 @@
+import * as fs from "node:fs";
+import { EMBEDDINGS_FILE, LEDGER_FILES, POSITIONS_FILE } from "../../config.ts";
 import type { GraphSnapshot } from "../core/contracts.ts";
 import type { GraphCostSummary } from "../core/cost-summary.ts";
 import { graphCostSummary } from "../core/cost-summary.ts";
@@ -35,3 +37,33 @@ export function graphCosts(): GraphCostSummary {
 		.map((s) => ({ filePath: s.filePath, extractions: s.extractions! }));
 	return graphCostSummary({ chats, sources, naming: stores.graphStore.readNamingRuns() });
 }
+
+/** The graph's version stamp (session-deletion wave 6): the max mtime
+ *  across every graph data file — ledgers, positions, embeddings. Moves
+ *  on ANY graph write (merge append, settle, embed, or a deletion's
+ *  atomic rewrite), never moves on reads, and needs no bookkeeping of
+ *  its own: the fs IS the counter. Consumers poll it (the activity feed
+ *  carries it; the DELETE response returns it) to know clusters/layout
+ *  must refetch — the "graph changed underneath me" signal. */
+export function graphRevision(): number {
+	let revision = 0;
+	for (const file of [
+		LEDGER_FILES.nodes,
+		LEDGER_FILES.edges,
+		LEDGER_FILES.events,
+		LEDGER_FILES.mappings,
+		LEDGER_FILES.sessions,
+		LEDGER_FILES.coverage,
+		LEDGER_FILES.clusterLabels,
+		LEDGER_FILES.namingRuns,
+		POSITIONS_FILE,
+		EMBEDDINGS_FILE,
+	]) {
+		try {
+			revision = Math.max(revision, fs.statSync(file).mtimeMs);
+		} catch {
+			/* absent — nothing has ever written it */
+		}
+	}
+	return revision;
+}
@@ -21,6 +21,7 @@

 import { extractionStatuses, type ExtractionPhase } from "../agent/subagents/extraction.ts";
 import { chatStore } from "../store/chats.ts";
+import { graphRevision } from "./graph.ts";
 import { listJobs } from "./jobs.ts";
 import type { JobRecord } from "../core/contracts.ts";

@@ -45,7 +46,13 @@ export interface ActivityExtraction {
 *  the blob disappears when the process ends. Cost math is NOT done here:
 *  raw usage rides on the records and the client folds it with the pure
 *  helpers in core/prices.ts (transport stays thin). */
-export function activityFeed(): { jobs: ActivityJob[]; extractions: ActivityExtraction[] } {
+/** The dock's whole world + the graph's version stamp (wave 6 session
+ *  deletion): the payload carries graphRevision (max mtime across the
+ *  graph data files — see server/graph.ts) so any view can detect "the
+ *  graph changed underneath me" (a merge landed, a deletion purged) and
+ *  refetch clusters/layout. Reads never move it; the DELETE response
+ *  returns the same stamp. */
+export function activityFeed(): { jobs: ActivityJob[]; extractions: ActivityExtraction[]; graphRevision: number } {
 	const chats = chatStore.listChats();
 	const jobs: ActivityJob[] = [];
 	for (const chat of chats) {
@@ -63,5 +70,9 @@ export function activityFeed(): { jobs: ActivityJob[]; extractions: ActivityExtr
 	}));
 	// oldest-first on last activity: the stable blob order (ISO strings sort chronologically)
 	jobs.sort((a, b) => a.updatedAt.localeCompare(b.updatedAt));
-	return { jobs, extractions: extractions.sort((a, b) => a.startedAt - b.startedAt) };
+	return {
+		jobs,
+		extractions: extractions.sort((a, b) => a.startedAt - b.startedAt),
+		graphRevision: graphRevision(),
+	};
 }