bunnyquery 1.5.7 → 1.6.2

package/src/engine/requests.ts

@@ -10,9 +10,9 @@
  *                                    state that stays in the consumer, not here;
  *                                    only the BgTaskEntry TYPE lives here)
  */
-import { buildIndexingSystemPrompt, buildIndexingUserMessage } from './prompts';
-import { isServerExtractable, isPagedReadFile, makeExtractPlaceholder, type ExtractDirective, type FileUrlDirective } from './office';
-import { chatEngineConfig, pollOpt } from './config';
+import { buildIndexingSystemPrompt, buildIndexingUserMessage, buildIndexingContinueMessage, buildIndexingRenderMessage, buildIndexingRenderContinueTemplate, buildIndexingWindowMessage } from './prompts';
+import { isServerExtractable, isPagedReadFile, isImageVisionFile, isWindowedReadFile, makeExtractPlaceholder, makeRenderPlaceholder, makeWindowPlaceholder, RENDER_PAGES_PER_WINDOW, type ExtractDirective, type FileUrlDirective } from './office';
+import { chatEngineConfig, pollOpt, windowedIndexingEnabled } from './config';
 
 export const ANTHROPIC_MESSAGES_API_URL = 'https://api.anthropic.com/v1/messages';
 const ANTHROPIC_MODELS_API_URL = 'https://api.anthropic.com/v1/models';
@@ -38,25 +38,47 @@ export const DEFAULT_OPENAI_MODEL = 'gpt-5.4';
 const mcpUrl = () => chatEngineConfig().mcpBaseUrl;
 const clientSecretRequest = (opts: any) => chatEngineConfig().clientSecretRequest(opts);
 
+// Resolve the per-image `detail` for OpenAI. The version match tolerates a
+// trailing variant/date suffix (`gpt-5.4-nano`, `-mini`, `-2026-01-01`, …):
+// previously the pattern was anchored with no suffix allowed, so EVERY suffixed
+// model silently fell through to 'auto' — i.e. the cheap tiers that most need
+// resolution were the ones getting downsampled images.
+//
+// Base models keep their exact previous behavior ('original'). A suffixed
+// variant resolves to 'high' rather than 'original': 'high' is the universally
+// supported value, and we have no way to confirm a given variant accepts
+// 'original' — sending an unsupported value would fail the whole request, which
+// is far worse than a slightly less detailed image.
 const getOpenAIImageDetail = (model?: string) => {
 	const normalized = (model || DEFAULT_OPENAI_MODEL).trim().toLowerCase();
-	const match = normalized.match(/^gpt-(\d+)(?:\.(\d+))?$/);
+	const match = normalized.match(/^gpt-(\d+)(?:\.(\d+))?(-[a-z0-9.\-]+)?$/);
 	if (!match) {
 		return DEFAULT_OPENAI_IMAGE_DETAIL;
 	}
 
 	const major = Number(match[1]);
 	const minor = match[2] === undefined ? null : Number(match[2]);
+	const isVariant = !!match[3];
 
-	if (major > 5) {
-		return 'original';
+	const supportsOriginal = major > 5 || (major === 5 && minor !== null && minor >= 4);
+	if (!supportsOriginal) {
+		return DEFAULT_OPENAI_IMAGE_DETAIL;
 	}
 
-	if (major === 5 && minor !== null && minor >= 4) {
-		return 'original';
-	}
+	return isVariant ? 'high' : 'original';
+};
 
-	return DEFAULT_OPENAI_IMAGE_DETAIL;
+// Per-image `detail` for WORKER-RENDERED document pages (the `_skapi_render`
+// path). Same resolution as above with one difference: these are dense scans
+// whose entire purpose is to be read, so 'auto' is never acceptable — it lets
+// the API downsample exactly the pixels the model needs to OCR. Floor it at
+// 'high'; models that support full-resolution 'original' still get it.
+//
+// Without this the worker falls back to its own model-blind default ('high'),
+// which silently denies the strongest models the 'original' detail they support.
+const getRenderImageDetail = (model?: string) => {
+	const detail = getOpenAIImageDetail(model);
+	return detail === DEFAULT_OPENAI_IMAGE_DETAIL ? 'high' : detail;
 };
 
 export type ClaudeRole = 'user' | 'assistant';
@@ -442,21 +464,102 @@ export type AttachmentSaveInfo = {
 	 * takes precedence over server-side office extraction / web_fetch.
 	 */
 	parsedContent?: string;
+	/**
+	 * True for a RESUME pass: a previous indexing pass could not finish this (large)
+	 * file, so continue it - always via readFileContent paging, with a "continue"
+	 * message telling the agent to resume from where the saved records leave off.
+	 */
+	continueIndexing?: boolean;
+	/**
+	 * For an image-vision file (PDF), the 0-based PAGE the render window should start at.
+	 * The worker renders [renderFrom, renderFrom+RENDER_PAGES_PER_WINDOW) and injects them
+	 * as image blocks; the resume loop advances this by a window each pass.
+	 */
+	renderFrom?: number;
 };
 
+// RESUME pass: continue indexing a large file a previous pass could not finish. Same
+// dispatch as notifyAgentSaveAttachment, but forced onto the paging path with a
+// "continue from where the saved records leave off" message.
+export async function notifyAgentContinueIndexing(info: AttachmentSaveInfo) {
+	return notifyAgentSaveAttachment({ ...info, continueIndexing: true });
+}
+
 // Background "save into knowledge" call (not a chat turn). A client-parsed file
 // (parser plugin) is inlined directly; otherwise office files get the
 // _skapi_extract directive + a placeholder, and everything else gets a URL.
 export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 	const { platform, service, owner, attachment, parsedContent } = info;
 
-	// Spreadsheets and PDFs are read by PAGING through readFileContent (grid rows +
-	// embedded photos / scanned page images), NOT inlined once - so they skip the inline
-	// server-extract and the agent is told to page the whole file (see pagedRead below).
-	const pagedRead = !parsedContent && isPagedReadFile(attachment.name, attachment.mime);
+	// A CONTINUE pass resumes a large file that a previous pass could not finish.
+	const continuing = !!info.continueIndexing;
+
+	// VISION files (PDFs) are delivered as rendered page IMAGES injected into the message by
+	// the worker (`_skapi_render`), because tool-result images render on neither provider.
+	// Both the first pass and every resume pass use this; renderFrom advances the page window.
+	const visionFile = !parsedContent && isImageVisionFile(attachment.name, attachment.mime);
+	const renderFrom = Math.max(0, info.renderFrom || 0);
+	const renderPlaceholder = visionFile ? makeRenderPlaceholder(attachment.storagePath) : undefined;
+	// Tell the worker what image `detail` to stamp on the injected page blocks.
+	// The worker is model-blind, so without this it applies a one-size default and
+	// the strongest models never get the 'original' detail they support. Only
+	// meaningful for OpenAI — Claude has no per-image detail knob and the worker
+	// ignores the field for it.
+	const renderDetail = platform === 'openai'
+		? getRenderImageDetail(info.model || DEFAULT_OPENAI_MODEL)
+		: undefined;
+	// `auto_continue` + `continue_text` hand the page loop to the WORKER: when its renderer
+	// reports pages left after this window, it builds the next pass from this template
+	// (substituting the window's 1-based start page for RENDER_FROM_TOKEN) and enqueues it
+	// itself. That is what makes a 500-page document index end-to-end — the loop no longer
+	// depends on the tab staying open, nor on the model correctly declaring itself unfinished.
+	const skapiRender = visionFile && renderPlaceholder
+		? {
+			_skapi_render: [
+				{
+					path: attachment.storagePath, from: renderFrom, count: RENDER_PAGES_PER_WINDOW,
+					placeholder: renderPlaceholder, name: attachment.name, mime: attachment.mime, detail: renderDetail,
+					auto_continue: true,
+					continue_text: buildIndexingRenderContinueTemplate(attachment, renderPlaceholder),
+				},
+			],
+		}
+		: {};
+
+	// SERVER-DRIVEN windowed read. When enabled, the worker reads one window of the file
+	// per request and continues from the reader's own cursor until the file is exhausted,
+	// so the traversal no longer lives inside the model's turn budget.
+	//
+	// Flag-gated because the BACKEND MUST SHIP FIRST: against a worker that does not strip
+	// `_skapi_window`, the directive reaches the provider as an unknown body field and the
+	// call fails terminally with no retry.
+	const windowedRead =
+		!visionFile && !parsedContent && windowedIndexingEnabled() &&
+		isWindowedReadFile(attachment.name, attachment.mime);
+	const windowPlaceholder = windowedRead ? makeWindowPlaceholder(attachment.storagePath) : undefined;
+	const skapiWindow = windowedRead && windowPlaceholder
+		? {
+			_skapi_window: [
+				{
+					path: attachment.storagePath,
+					cursor: null,
+					placeholder: windowPlaceholder,
+					name: attachment.name,
+					mime: attachment.mime,
+					kind: 'window',
+					auto_continue: true,
+					continue_text: buildIndexingWindowMessage(attachment, windowPlaceholder, true),
+				},
+			],
+		}
+		: {};
+
+	// Spreadsheets are read by PAGING through readFileContent (grid rows), NOT inlined - so
+	// they skip the inline server-extract and the agent is told to page the whole file.
+	const pagedRead = !visionFile && !windowedRead && (continuing || (!parsedContent && isPagedReadFile(attachment.name, attachment.mime)));
 
 	// Client-parsed content wins over server-side extraction.
-	const serverExtract = !parsedContent && !pagedRead && isServerExtractable(attachment.name, attachment.mime);
+	const serverExtract = !visionFile && !windowedRead && !continuing && !parsedContent && !pagedRead && isServerExtractable(attachment.name, attachment.mime);
 	const placeholder = serverExtract ? makeExtractPlaceholder(attachment.storagePath) : undefined;
 	const extractContent: ExtractDirective[] | undefined =
 		serverExtract && placeholder
@@ -465,16 +568,22 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 	const skapiExtract =
 		extractContent && extractContent.length ? { _skapi_extract: extractContent } : {};
 
-	const userMessage = buildIndexingUserMessage(
-		attachment,
-		parsedContent
-			? { inlineContent: parsedContent }
-			: placeholder
-				? { inlineContentPlaceholder: placeholder }
-				: pagedRead
-					? { pagedRead: true }
-					: undefined,
-	);
+	const userMessage = (visionFile && renderPlaceholder)
+		? buildIndexingRenderMessage(attachment, renderPlaceholder, renderFrom)
+		: (windowedRead && windowPlaceholder)
+		? buildIndexingWindowMessage(attachment, windowPlaceholder, false)
+		: continuing
+			? buildIndexingContinueMessage(attachment)
+			: buildIndexingUserMessage(
+				attachment,
+				parsedContent
+					? { inlineContent: parsedContent }
+					: placeholder
+						? { inlineContentPlaceholder: placeholder }
+						: pagedRead
+							? { pagedRead: true }
+							: undefined,
+			);
 
 	const systemPrompt = buildIndexingSystemPrompt({
 		service,
@@ -501,6 +610,8 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 				model: resolvedModel,
 				max_output_tokens: MAX_TOKENS,
 				...skapiExtract,
+				...skapiRender,
+				...skapiWindow,
 				input: [
 					{ role: 'system', content: systemPrompt },
 					{
@@ -548,6 +659,8 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 			model: resolvedModel,
 			max_tokens: MAX_TOKENS,
 			...skapiExtract,
+			...skapiRender,
+			...skapiWindow,
 			system: [
 				{
 					type: 'text',
@@ -672,6 +785,23 @@ export async function listOpenAIModels(service: string, owner: string) {
 // so the chat-history BETWEEN query never includes bg-queue items. '-' (45) works.
 export const BG_INDEXING_QUEUE_SUFFIX = '-bg';
 
+/**
+ * True when a request belongs to the background-indexing queue.
+ *
+ * Accepts BOTH shapes this value arrives in: the bare queue name the client sends
+ * ("<userId>-bg"), and the server qid that comes back on history/poll responses
+ * ("<service>:<queue>|<seq>"). Testing the tail of the raw value only works for the
+ * first: a qid ends in "|<seq>", so `endsWith('-bg')` is always false for it — which
+ * silently meant history items were NEVER recognised as background tasks.
+ */
+export function isBgIndexingQueue(queueName?: string): boolean {
+	if (typeof queueName !== 'string' || !queueName) return false;
+	const prefix = queueName.split('|')[0];
+	const idx = prefix.lastIndexOf(':');
+	const name = idx === -1 ? prefix : prefix.slice(idx + 1);
+	return name.slice(-BG_INDEXING_QUEUE_SUFFIX.length) === BG_INDEXING_QUEUE_SUFFIX;
+}
+
 // Pending background-indexing task descriptor. NOTE: the live mutable queue
 // (a Vue `reactive([])` in agent.vue, a plain array in bunnyquery) is app-level
 // state owned by the consumer — only the TYPE lives in the engine.
@@ -686,8 +816,23 @@ export type BgTaskEntry = {
 	size?: number;
 	status: 'running' | 'pending';
 	poll: ((opts: { latency: number }) => Promise<any>) | undefined;
+	/** How many CONTINUE passes have already run for this file (resume-across-passes). */
+	resumePass?: number;
 };
 
+// Token the indexing agent appends to its final message ONLY when it has fully read and
+// saved the whole file. Its ABSENCE is what tells the client to run another CONTINUE pass.
+//
+// Applies to the TEXT/GRID paging path only. The vision path (rendered PDF pages) no longer
+// asks the model whether it is finished — the worker advances that loop off the renderer's
+// page count — so this marker has no say in whether a PDF keeps going.
+export const INDEXING_COMPLETE_MARKER = 'INDEXING_COMPLETE';
+// Cap on CONTINUE passes per file, so a file the agent can never mark complete (or a
+// pathological loop) stops instead of re-dispatching forever. The text/grid paging path
+// reads MANY windows within a single pass (the agent loops readFileContent in one turn), so
+// a small cap suffices.
+export const MAX_INDEXING_RESUME_PASSES = 6;
+
 export async function getChatHistory(
 	params: { service?: string; owner?: string; platform: 'claude' | 'openai'; queue?: string },
 	fetchOptions: Record<string, any>,