bunnyquery 1.8.5 → 1.8.8

package/src/engine/requests.ts

@@ -13,6 +13,9 @@
 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';
+// Output sizing lives in budget.ts so the request cap and the reserve the input
+// budget subtracts cannot drift; getMaxOutputTokens also clamps per model.
+import { getMaxOutputTokens } from './budget';
 
 export const ANTHROPIC_MESSAGES_API_URL = 'https://api.anthropic.com/v1/messages';
 const ANTHROPIC_MODELS_API_URL = 'https://api.anthropic.com/v1/models';
@@ -26,13 +29,12 @@ const WEB_FETCH_MAX_CONTENT_TOKENS = 200000;
 
 export const OPENAI_RESPONSES_API_URL = 'https://api.openai.com/v1/responses';
 const OPENAI_MODELS_API_URL = 'https://api.openai.com/v1/models';
-const MAX_TOKENS = 25000;
 const DEFAULT_OPENAI_IMAGE_DETAIL = 'auto';
 const OPENAI_WEB_SEARCH_ENABLED = true;
 const OPENAI_WEB_SEARCH_EXTERNAL_WEB_ACCESS = true;
 export const MCP_NAME = 'BunnyQuery';
 
-export const DEFAULT_CLAUDE_MODEL = 'claude-sonnet-4-6';
+export const DEFAULT_CLAUDE_MODEL = 'claude-sonnet-5';
 export const DEFAULT_OPENAI_MODEL = 'gpt-5.6-luna';
 
 const mcpUrl = () => chatEngineConfig().mcpBaseUrl;
@@ -205,7 +207,7 @@ const isOldestNano = (model?: string) => {
 // full one.
 //
 // This is the lever that does not risk a 400. The output budget is one number for the whole
-// pass (MAX_TOKENS, and reasoning is billed against it), so a window of 5 dense pages leaves
+// pass (getMaxOutputTokens, and reasoning is billed against it), so a window of 5 dense pages leaves
 // a small model a couple of thousand tokens per page and it starts sampling rows instead of
 // transcribing them - which is exactly the "saved 5 line items" on a page holding twenty.
 // Halving the window does not raise the cap, it just stops dividing it so many ways, and the
@@ -554,7 +556,7 @@ export async function callClaudeWithPublicMcp(
 		owner,
 		userId,
 		model: model || DEFAULT_CLAUDE_MODEL,
-		maxTokens: MAX_TOKENS,
+		maxTokens: getMaxOutputTokens('claude', model || DEFAULT_CLAUDE_MODEL),
 		system,
 		extractContent,
 		fileUrls,
@@ -622,7 +624,7 @@ export async function callOpenAIWithPublicMcp(
 		},
 		data: {
 			model: resolvedModel,
-			max_output_tokens: MAX_TOKENS,
+			max_output_tokens: getMaxOutputTokens('openai', resolvedModel),
 			...(extractContent && extractContent.length
 				? { _skapi_extract: extractContent }
 				: {}),
@@ -716,6 +718,37 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 	// A CONTINUE pass resumes a large file that a previous pass could not finish.
 	const continuing = !!info.continueIndexing;
 
+	// Durable run record, minted the moment a run's FIRST pass is enqueued (every
+	// first-pass site funnels through this function, so one mint covers them all;
+	// resume passes belong to the existing run and must not touch it). Ordering is
+	// safe by construction: every caller runs its delete-then-repost + src:: mint
+	// BEFORE calling here, so the record's `reference: src::<path>` resolves. The
+	// dispatch promise is tapped below so an enqueue that never reached the queue
+	// closes the record as an error instead of leaving 'working' dangling.
+	if (!continuing) {
+		upsertIndexRunRecordSafe(service, attachment.storagePath, {
+			status: 'working',
+			filename: attachment.name,
+			started: Date.now(),
+			queue: bgIndexingQueueName(info.userId, service),
+			platform: platform,
+		});
+	}
+	const tapDispatchFailure = (p: Promise<any>): Promise<any> => {
+		if (continuing) return p;
+		return p.then(
+			(ack: any) => ack,
+			(err: any) => {
+				upsertIndexRunRecordSafe(service, attachment.storagePath, {
+					status: 'error',
+					finished: Date.now(),
+					error: (err && (err.message || String(err))) || 'The indexing request could not be enqueued.',
+				});
+				throw err;
+			},
+		);
+	};
+
 	// 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.
@@ -816,6 +849,25 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 			}
 			: {};
 
+	// Ask the worker to re-sign this file's url at EXECUTION time.
+	//
+	// The url below was minted when the file was uploaded. Indexing for a project
+	// runs on ONE FIFO group, one pass at a time, so a row queued behind a bulk
+	// upload can wait hours or days before it fires - by which point that url can
+	// be dead, the provider's fetch returns nothing, and the file is recorded as
+	// indexed with an empty index behind it. The worker rebuilds the body from the
+	// row on every delivery, so re-signing there means the url only has to outlive
+	// ONE invocation however long the wait was.
+	//
+	// Sent for every indexing pass, including CONTINUE passes: a chain spanning
+	// days is exactly where the baked url is oldest. Harmless where the file's
+	// content arrives another way (server-side extraction, rendered pages) - the
+	// url still appears as the attachment link, and a dead link in front of the
+	// model is worth avoiding either way.
+	const skapiFileUrls = attachment.url && attachment.storagePath
+		? { _skapi_file_urls: [{ path: attachment.storagePath, url: attachment.url }] }
+		: {};
+
 	const userMessage = (visionFile && renderPlaceholder)
 		? buildIndexingRenderMessage(attachment, renderPlaceholder, renderFrom)
 		: (windowedRead && windowPlaceholder)
@@ -845,7 +897,7 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 	if (platform === 'openai') {
 		const resolvedModel = info.model || DEFAULT_OPENAI_MODEL;
 		const imageDetail = getOpenAIImageDetail(resolvedModel);
-		return clientSecretRequest({
+		return tapDispatchFailure(clientSecretRequest({
 			clientSecretName: 'openai',
 			queue: bgIndexingQueueName(info.userId, service),
 			service,
@@ -859,12 +911,13 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 			},
 			data: {
 				model: resolvedModel,
-				max_output_tokens: MAX_TOKENS,
+				max_output_tokens: getMaxOutputTokens('openai', resolvedModel),
 				// Nano-only transcription knobs. Indexing only; see variantIndexingOptions.
 				...variantIndexingOptions(resolvedModel),
 				...skapiExtract,
 				...skapiRender,
 				...skapiWindow,
+				...skapiFileUrls,
 				input: [
 					{ role: 'system', content: systemPrompt },
 					{
@@ -890,11 +943,11 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 						: []),
 				],
 			},
-		});
+		}));
 	}
 
 	const resolvedModel = info.model || DEFAULT_CLAUDE_MODEL;
-	return clientSecretRequest({
+	return tapDispatchFailure(clientSecretRequest({
 		clientSecretName: 'claude',
 		queue: bgIndexingQueueName(info.userId, service),
 		service,
@@ -910,10 +963,11 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 		},
 		data: {
 			model: resolvedModel,
-			max_tokens: MAX_TOKENS,
+			max_tokens: getMaxOutputTokens('claude', resolvedModel),
 			...skapiExtract,
 			...skapiRender,
 			...skapiWindow,
+			...skapiFileUrls,
 			system: [
 				{
 					type: 'text',
@@ -949,7 +1003,7 @@ export async function notifyAgentSaveAttachment(info: AttachmentSaveInfo) {
 				},
 			],
 		},
-	});
+	}));
 }
 
 export function extractClaudeText(response: any) {
@@ -1038,6 +1092,79 @@ 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';
 
+/**
+ * unique_id of the durable "indexing finished" marker record for a stored file.
+ *
+ * Written by the BACKEND (the polling worker calls the MCP server's
+ * /internal/index-complete at the end of an auto_continue chain whose final
+ * window reported no more content) and, for completions a client knows
+ * deterministically (single-pass settle, client-chain completion token), by the
+ * consumer's mintIndexDoneMarker hook — never by the model.
+ * The marker record carries `reference: "src::<path>"`, so the reindex flow's
+ * delete of the src:: record cascades to it and a re-run starts unmarked.
+ *
+ * Existence semantics: present = the whole file was read to the end. Absent =
+ * unknown (still running, failed partway, indexed before this marker existed,
+ * or a single-pass run minted before the client hook existed) - callers must
+ * fall back to the live-queue probe (fetchLiveIndexingKeys) before reading
+ * absence as anything.
+ */
+export function indexDoneUniqueId(storagePath: string): string {
+	return 'done::' + storagePath;
+}
+
+/**
+ * unique_id of the per-file indexing RUN record.
+ *
+ * One record per storage path, newest run wins (a reindex's delete-then-repost
+ * of src:: cascade-deletes the old record first, exactly like done::). Minted
+ * status='working' by the client the moment it enqueues a run's FIRST pass, and
+ * closed (done/error/cancelled) by whichever side observes the ending: the
+ * worker via the MCP internal routes for worker-driven chains, the client for
+ * deterministic settles, cancels, and dispatch failures. It exists so chat rows
+ * and files-page badges can answer "which runs exist and how did they end"
+ * from ONE records query instead of scanning bg history.
+ *
+ * A 'working' record is a claim, not proof: a chain that dies without reaching
+ * any error path leaves it dangling, so readers must treat a stale 'working'
+ * (old `started`, no live-queue confirmation) as unknown, never as live.
+ */
+export function runIndexUniqueId(storagePath: string): string {
+	return 'run::' + storagePath;
+}
+
+export type IndexRunStatus = 'working' | 'done' | 'error' | 'cancelled';
+
+export type IndexRunPatch = {
+	status: IndexRunStatus;
+	filename?: string;
+	started?: number;
+	finished?: number;
+	error?: string;
+	queue?: string;
+	/** Chat that owns this run. A run:: record is keyed by storage path alone,
+	 *  but a chat is per (project, platform) — without this the Claude chat's
+	 *  runs surfaced as rows in the same project's ChatGPT chat, where their
+	 *  passes can never load and the queue probe can never see them. */
+	platform?: 'claude' | 'openai';
+};
+
+/**
+ * Fire-and-forget wrapper over the consumer's upsertIndexRunRecord hook.
+ * Safe everywhere: missing hook, unconfigured engine, and consumer throws all
+ * reduce to a no-op — a run record must never be able to break the run itself.
+ */
+export function upsertIndexRunRecordSafe(service: string, storagePath: string, patch: IndexRunPatch): void {
+	if (!service || !storagePath) return;
+	try {
+		const hook = chatEngineConfig().upsertIndexRunRecord;
+		if (typeof hook !== 'function') return;
+		hook({ service, storagePath, patch });
+	} catch (e) {
+		// best-effort by contract
+	}
+}
+
 /**
  * The one place the background-indexing queue name is spelled out. The backend
  * serialises requests sharing a queue name and runs different names in PARALLEL,
@@ -1133,7 +1260,21 @@ export const CHAT_HISTORY_PAGE_LIMIT = 500;
  * everything already finished.
  */
 export async function getChatHistory(
-	params: { service?: string; owner?: string; platform: 'claude' | 'openai'; queue?: string; status?: 'pending' | 'running' | 'resolved' | 'failed' },
+	params: {
+		service?: string; owner?: string; platform: 'claude' | 'openai'; queue?: string;
+		status?: 'pending' | 'running' | 'resolved' | 'failed';
+		/** Exact-queue listing: without it the qid range is a PREFIX match, so
+		 *  queue "u1" also returns "u1-bg" rows. Requires the updated polling
+		 *  lambda; older backends ignore it (harmless, wider results). */
+		queue_exact?: boolean;
+		/** Label/marker STUBS instead of full bodies (see the polling lambda).
+		 *  Older backends ignore it and return full items. */
+		compact?: boolean;
+		/** Drop one queue's rows from an id-prefix listing — how the surface
+		 *  chat is fetched WITHOUT the bg-indexing queue while legacy items on
+		 *  odd queue names survive. Older backends ignore it. */
+		queue_exclude?: string;
+	},
 	fetchOptions: Record<string, any>,
 ) {
 	const url =
@@ -1148,6 +1289,9 @@ export async function getChatHistory(
 		{ service: params.service, owner: params.owner },
 		params.queue ? { queue: params.queue } : {},
 		params.status ? { status: params.status } : {},
+		params.queue_exact ? { queue_exact: true } : {},
+		params.compact ? { compact: true } : {},
+		params.queue_exclude ? { queue_exclude: params.queue_exclude } : {},
 	);
 
 	return chatEngineConfig().clientSecretRequestHistory(
@@ -1155,3 +1299,12 @@ export async function getChatHistory(
 		Object.assign({ ascending: false, limit: CHAT_HISTORY_PAGE_LIMIT }, fetchOptions),
 	);
 }
+
+/** Full server-side id of one history item, for a csr-poll POINT LOOKUP (the
+ *  single-item path returns the item WITH bodies — how an expanded row fetches
+ *  the passes a compact listing stubbed out). Mirrors the id the SDK builds:
+ *  `[METHOD]url#service:` + the item's own `stamp:entropy` id. */
+export function buildHistoryItemFullId(platform: 'claude' | 'openai', service: string, itemId: string): string {
+	const url = platform === 'claude' ? ANTHROPIC_MESSAGES_API_URL : OPENAI_RESPONSES_API_URL;
+	return `[POST]${url.toLowerCase()}#${service}:${itemId}`;
+}