Hotfix - Rag reingest - #19753

Check if this issue is valid — if so, understand the root cause and fix it. At packages/server/src/sdk/workspace/ai/rag/ragQueue.ts, line 215:

<comment>S3 object-store 403/404 failures do not satisfy this `HTTPError`-only check. Normalize the object-store status fields as well, otherwise missing or inaccessible uploads still undergo all retries instead of taking the permanent-failure path.</comment>

<file context>
@@ -194,31 +200,42 @@ const loadFileBuffer = async (objectKey: string): Promise<Buffer> => {
   const attempts = job.opts.attempts || 1
   const isFinalAttempt = job.attemptsMade + 1 >= attempts
+  const isStoreAccessError =
+    error instanceof HTTPError && (error.status === 403 || error.status === 404)
+  const errorMessage =
+    error instanceof Error ? error.message : "Failed to process uploaded file"
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/server/src/api/controllers/row/internal.ts, line 165:

<comment>This new mismatch guard throws a plain string, which koa turns into a generic 500 without the message, so API clients can't surface "Supplied tableId doesn't match...". Throw `new HTTPError("Supplied tableId doesn't match the row's tableId", 400)` instead (HTTPError is already imported in this file).</comment>

<file context>
@@ -152,6 +152,18 @@ export async function bulkDestroy(ctx: UserCtx) {
+    rows.some((row: Row) => row.tableId && row.tableId !== tableId) ||
+    dbRows.some(row => row.tableId !== tableId)
+  ) {
+    throw "Supplied tableId doesn't match the row's tableId"
+  }
 
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/server/src/sdk/workspace/ai/knowledgeBase/geminiFileStore.ts, line 242:

<comment>This maps every 403/404 from LiteLLM `/v1/rag/ingest` to a Gemini store failure, including unrelated LiteLLM auth or route errors. Only show the reset guidance when the response identifies a `fileSearchStores` failure; otherwise preserve the upstream error.</comment>

<file context>
@@ -223,6 +238,10 @@ export async function ingestGeminiFile({
   })
 
+  if (!response.ok) {
+    throwIfStoreAccessError(response.status)
+  }
+
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/server/src/sdk/workspace/ai/rag/ragQueue.ts, line 217:

<comment>`errorMessage` now discards `.message` from thrown non-`Error` objects, losing actionable failure details that the previous optional-property read preserved. Keep object messages when constructing the persisted error text.</comment>

<file context>
@@ -194,31 +200,42 @@ const loadFileBuffer = async (objectKey: string): Promise<Buffer> => {
+  const isStoreAccessError =
+    error instanceof HTTPError && (error.status === 403 || error.status === 404)
+  const errorMessage =
+    error instanceof Error ? error.message : "Failed to process uploaded file"
 
-  if (!isFinalAttempt) {
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/server/src/sdk/workspace/ai/rag/ragQueue.spec.ts, line 64:

<comment>The retry behavior this hotfix restores lives in getQueue()'s jobOptions (attempts: 5, exponential backoff), but these tests never exercise it: BudibaseQueue is mocked away and makeJob hardcodes opts.attempts: 5, duplicating the production constant. A regression that drops jobOptions.attempts back to 1 would leave both "keeps retrying HTTP" tests green, so the test suite would not catch the very bug the hotfix fixes. Keep the processor unit tests, but also pin the retry configuration to the real queue, e.g. assert getQueue() registers attempts 5 with exponential backoff, or build the test job's opts from the queue's jobOptions instead of hardcoding them.</comment>

<file context>
@@ -0,0 +1,154 @@
+        knowledgeBaseId: "kb-1",
+        fileId: "file-1",
+      },
+      opts: { attempts: 5, timeout: 600_000 },
+      attemptsMade,
+      discard: jest.fn(),
</file context>