@kirchdev/duxt 0.10.1-dev-main.8-902bddd → 0.10.1-dev-main.10-e43ad25

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://www.schemastore.org/package.json",
   "name": "@kirchdev/duxt",
-  "version": "0.10.1-dev-main.8-902bddd",
+  "version": "0.10.1-dev-main.10-e43ad25",
   "description": "duxt is a Nuxt layer: extend it and your docs/ folder becomes a site, with theme, search, API reference and llms.txt included. Point it at other repositories, or at tags of the same one, and each becomes a version.",
   "keywords": [
     "content-v3",

package/server/plugins/content-import-lifetime.ts

@@ -10,10 +10,10 @@
  * reader who gives up, a crawler with a timeout, a prefetch the router drops:
  * any of them stops that replay halfway, and the row is never flipped. Every
  * later read of that collection then waits on `ready` for 90 seconds and
- * fails, on every isolate, until the row is removed by hand — and a docs page
- * reads every version's collection to draw its version switcher, so one stuck
- * collection hangs every page of every version. duxt.app ran into exactly
- * that after the v0.10.0 deploy.
+ * fails, on every isolate, until `content-restore-recovery.ts` clears the row —
+ * and a docs page reads every version's collection to draw its version
+ * switcher, so one stuck collection hangs every page of every version.
+ * duxt.app ran into exactly that after the v0.10.0 deploy.
  *
  * `waitUntil` is the one thing a Worker lets outlive a disconnect, so every
  * request hands it a promise that settles when the request is done. Anything

package/server/plugins/content-restore-recovery.ts

@@ -0,0 +1,65 @@
+import {
+  duxtRecoverContentRestores,
+  type DuxtD1
+} from '../utils/content-restore';
+
+/**
+ * Clears Content restores a cancelled Worker left half done, from inside the
+ * Worker, on D1.
+ *
+ * `content-import-lifetime.ts` keeps a restore running past a disconnect, but
+ * only for the platform's grace period, and a row that was stranded before it
+ * — or by a deploy that cut a running restore off — stays unready for good:
+ * every read of that collection then waits 90 seconds and fails, and a docs
+ * page reads every version's collection to draw its switcher. duxt.app sat
+ * like that after the v0.10.0 deploy until the row was removed by hand.
+ *
+ * It runs here rather than in the deploy because the Worker is the one thing
+ * that already holds the binding: a cleanup step in CI would need a token with
+ * D1 rights for every repository that reads it, and would help no site but the
+ * one whose workflow carries it.
+ *
+ * At most once a minute per isolate, after the response, so no reader waits on
+ * it. A failure is logged and dropped: this is a repair, and a missing table
+ * on a fresh database is not an error.
+ */
+const INTERVAL_MS = 60_000;
+
+let last = 0;
+
+export default defineNitroPlugin((nitroApp) => {
+  nitroApp.hooks.hook('request', (event) => {
+    const env = event.context.cloudflare?.env as
+      | Record<string, unknown>
+      | undefined;
+    if (!env || !event.waitUntil) return;
+
+    const database = useRuntimeConfig(event).content?.database as
+      | { type?: string; bindingName?: string; binding?: string }
+      | undefined;
+    if (database?.type !== 'd1') return;
+
+    const db = env[database.bindingName || database.binding || 'DB'] as
+      | DuxtD1
+      | undefined;
+    if (!db) return;
+
+    const now = Date.now();
+    if (now - last < INTERVAL_MS) return;
+    last = now;
+
+    event.waitUntil(
+      duxtRecoverContentRestores(db, now)
+        .then((removed) => {
+          if (removed.length) {
+            console.warn(
+              `[duxt] cleared abandoned Content restores: ${removed.join(', ')}`
+            );
+          }
+        })
+        .catch((error) => {
+          console.warn('[duxt] Content restore check failed', error);
+        })
+    );
+  });
+});

package/server/utils/content-restore.ts

@@ -0,0 +1,91 @@
+/**
+ * The part of a D1 binding this file uses — written out rather than imported,
+ * because the layer does not depend on Cloudflare's types and no other
+ * runtime ever reaches this code.
+ */
+export interface DuxtD1 {
+  prepare(sql: string): DuxtD1Statement;
+  batch(statements: DuxtD1Statement[]): Promise<unknown>;
+}
+
+export interface DuxtD1Statement {
+  bind(...values: unknown[]): DuxtD1Statement;
+  all<T>(): Promise<{ results: T[] }>;
+  run(): Promise<unknown>;
+}
+
+/**
+ * Twice the 90 seconds Content waits for another restore before giving up.
+ * A restore takes about ten seconds a collection on duxt.app, so a row still
+ * unready after this has nobody left writing it.
+ */
+export const DUXT_STALE_RESTORE_MS = 180_000;
+
+/** Where a row was first seen unready. Content owns `_content_info`; this is ours. */
+const SEEN = '_duxt_content_unready';
+
+/**
+ * Removes every Content restore that was abandoned halfway, so the next read
+ * of that collection restores it again instead of waiting on it forever.
+ *
+ * Content marks a collection `ready = 0` in `_content_info`, replays its dump
+ * and flips the row as the dump's last statement. A Worker cancelled before
+ * that statement leaves the row unready for good, and every later read waits
+ * 90 seconds and fails — see `server/plugins/content-restore-recovery.ts`.
+ *
+ * The row carries no timestamp, and an unready row is also exactly what a
+ * restore IN PROGRESS looks like, so a single look cannot tell the two apart.
+ * Two looks can: the first records when a row was seen unready, and a later
+ * one removes it only if the SAME version is still unready past the threshold.
+ * A new deploy writes a new version, which starts the clock again.
+ *
+ * Returns the ids it removed.
+ */
+export async function duxtRecoverContentRestores(
+  db: DuxtD1,
+  now: number,
+  staleMs = DUXT_STALE_RESTORE_MS
+): Promise<string[]> {
+  const unready = await db
+    .prepare('SELECT id, version FROM _content_info WHERE ready = 0')
+    .all<{ id: string; version: string }>();
+
+  await db.batch([
+    db.prepare(
+      `CREATE TABLE IF NOT EXISTS ${SEEN} (id TEXT PRIMARY KEY, version TEXT NOT NULL, since INTEGER NOT NULL)`
+    ),
+    // A row that finished, or that Content replaced, is forgotten — otherwise
+    // its old clock would condemn the next restore of the same version.
+    db.prepare(
+      `DELETE FROM ${SEEN} WHERE NOT EXISTS (SELECT 1 FROM _content_info AS info WHERE info.id = ${SEEN}.id AND info.version = ${SEEN}.version AND info.ready = 0)`
+    ),
+    ...unready.results.map((row) =>
+      db
+        .prepare(
+          `INSERT INTO ${SEEN} (id, version, since) VALUES (?, ?, ?) ON CONFLICT (id) DO NOTHING`
+        )
+        .bind(row.id, row.version, now)
+    )
+  ]);
+
+  const stale = await db
+    .prepare(`SELECT id, version FROM ${SEEN} WHERE since <= ?`)
+    .bind(now - staleMs)
+    .all<{ id: string; version: string }>();
+  if (!stale.results.length) return [];
+
+  // `ready = 0` and the version in the condition: a restore that finished, or
+  // a deploy that replaced the row, since the look above keeps its row.
+  await db.batch(
+    stale.results.flatMap((row) => [
+      db
+        .prepare(
+          'DELETE FROM _content_info WHERE id = ? AND version = ? AND ready = 0'
+        )
+        .bind(row.id, row.version),
+      db.prepare(`DELETE FROM ${SEEN} WHERE id = ?`).bind(row.id)
+    ])
+  );
+
+  return stale.results.map((row) => row.id);
+}