@okf/ootils 1.41.1 → 1.41.2

package/dist/universal.js

@@ -966,6 +966,58 @@ var BASE_BULLMQ_CONFIG = {
       }
     }
   },
+  AI_AUTO_ANNOTATE_PREP_QUEUE: {
+    // PREP queue — the front of the per-doc Flow pipeline. The FE-facing
+    // /AIAutoAnnotate handler no longer fetches + summarizes + chunks +
+    // enqueues each doc inline (that serial, LLM-heavy loop blocked the HTTP
+    // request and risked App Engine clipping large batches mid-loop, silently
+    // dropping every doc past the cutoff). Instead the handler computes the
+    // batch-level prereqs ONCE (7th criterion + platform-derived categories)
+    // and enqueues one PREP job per doc here, then returns fast.
+    //
+    // Each prep job's worker (okf-sub) calls okf-be /internal/prepDoc, which
+    // does the per-doc work: fetch → summarizeDocument (warms the doc-level
+    // summary cache) → chunk fields → enqueue that doc's Flow (parent on
+    // AI_AUTO_ANNOTATE_QUEUE + one child per chunk on the CHUNK queue). So the
+    // Flow parents now get created rolling, as each prep job completes, rather
+    // than all up-front in the request. A prep failure isolates to its one doc
+    // (that doc is skipped); sibling prep jobs keep going.
+    id: "ai-auto-annotate-prep-queue",
+    queueConfig: {
+      defaultJobOptions: {
+        // attempts:1 — a retry would re-summarize (cache-HIT, cheap) but then
+        // re-enqueue the doc's Flow, double-annotating the doc. The rest of
+        // the per-doc Flow pipeline is attempts:1 for the same fail-loud
+        // reason (a retry just re-fires expensive LLM work).
+        attempts: 1,
+        backoff: {
+          type: "exponential",
+          delay: 5e3
+        },
+        removeOnComplete: 30,
+        removeOnFail: 100
+      },
+      streams: {
+        events: {
+          maxLen: 10
+        }
+      }
+    },
+    workerConfig: {
+      // Each prep job = one Mongo doc fetch + ONE summarize LLM call + a
+      // deterministic chunk + a Flow enqueue. It's lighter than a chunk job
+      // (which does ~4 LLM calls), so we can run more in parallel — 10 keeps
+      // prep comfortably AHEAD of the downstream chunk queue (concurrency 5),
+      // which is the real throughput cap. Going much higher than that buys
+      // little: prep would just drain faster into a chunk queue that still
+      // processes 5 at a time, while adding concurrent okf-be /internal/prepDoc
+      // load + concurrent summarize calls against the shared OpenAI TPM budget.
+      concurrency: 10,
+      lockDuration: 3e5,
+      // 5 min — generous ceiling over the 180s summarizer timeout
+      maxStalledCount: 1
+    }
+  },
   AI_AUTO_ANNOTATE_QUEUE: {
     // PARENT queue in the per-doc Flow. One job per doc; child jobs (one
     // per chunk) live on AI_AUTO_ANNOTATE_CHUNK_QUEUE. BullMQ Flow fires

package/dist/universal.mjs

@@ -896,6 +896,58 @@ var BASE_BULLMQ_CONFIG = {
       }
     }
   },
+  AI_AUTO_ANNOTATE_PREP_QUEUE: {
+    // PREP queue — the front of the per-doc Flow pipeline. The FE-facing
+    // /AIAutoAnnotate handler no longer fetches + summarizes + chunks +
+    // enqueues each doc inline (that serial, LLM-heavy loop blocked the HTTP
+    // request and risked App Engine clipping large batches mid-loop, silently
+    // dropping every doc past the cutoff). Instead the handler computes the
+    // batch-level prereqs ONCE (7th criterion + platform-derived categories)
+    // and enqueues one PREP job per doc here, then returns fast.
+    //
+    // Each prep job's worker (okf-sub) calls okf-be /internal/prepDoc, which
+    // does the per-doc work: fetch → summarizeDocument (warms the doc-level
+    // summary cache) → chunk fields → enqueue that doc's Flow (parent on
+    // AI_AUTO_ANNOTATE_QUEUE + one child per chunk on the CHUNK queue). So the
+    // Flow parents now get created rolling, as each prep job completes, rather
+    // than all up-front in the request. A prep failure isolates to its one doc
+    // (that doc is skipped); sibling prep jobs keep going.
+    id: "ai-auto-annotate-prep-queue",
+    queueConfig: {
+      defaultJobOptions: {
+        // attempts:1 — a retry would re-summarize (cache-HIT, cheap) but then
+        // re-enqueue the doc's Flow, double-annotating the doc. The rest of
+        // the per-doc Flow pipeline is attempts:1 for the same fail-loud
+        // reason (a retry just re-fires expensive LLM work).
+        attempts: 1,
+        backoff: {
+          type: "exponential",
+          delay: 5e3
+        },
+        removeOnComplete: 30,
+        removeOnFail: 100
+      },
+      streams: {
+        events: {
+          maxLen: 10
+        }
+      }
+    },
+    workerConfig: {
+      // Each prep job = one Mongo doc fetch + ONE summarize LLM call + a
+      // deterministic chunk + a Flow enqueue. It's lighter than a chunk job
+      // (which does ~4 LLM calls), so we can run more in parallel — 10 keeps
+      // prep comfortably AHEAD of the downstream chunk queue (concurrency 5),
+      // which is the real throughput cap. Going much higher than that buys
+      // little: prep would just drain faster into a chunk queue that still
+      // processes 5 at a time, while adding concurrent okf-be /internal/prepDoc
+      // load + concurrent summarize calls against the shared OpenAI TPM budget.
+      concurrency: 10,
+      lockDuration: 3e5,
+      // 5 min — generous ceiling over the 180s summarizer timeout
+      maxStalledCount: 1
+    }
+  },
   AI_AUTO_ANNOTATE_QUEUE: {
     // PARENT queue in the per-doc Flow. One job per doc; child jobs (one
     // per chunk) live on AI_AUTO_ANNOTATE_CHUNK_QUEUE. BullMQ Flow fires

package/package.json

@@ -3,7 +3,7 @@
   "publishConfig": {
     "access": "public"
   },
-  "version": "1.41.1",
+  "version": "1.41.2",
   "description": "Utility functions for both browser and Node.js",
   "main": "dist/index.js",
   "module": "dist/index.mjs",