bunnyquery 1.10.5 → 1.10.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bunnyquery",
-  "version": "1.10.5",
+  "version": "1.10.7",
   "description": "Embeddable BunnyQuery AI chat widget + its framework-agnostic chat engine",
   "main": "bunnyquery.js",
   "exports": {

package/src/engine/history.ts

@@ -792,6 +792,12 @@ export function mapHistoryListToMessages(list: any[], platform: 'claude' | 'open
 		// if one is missing (older records only carried `updated`).
 		var createdTs = Number(item && item.created);
 		var updatedTs = Number(item && item.updated);
+		// When the WORKER began executing this pass, not when it was enqueued. The
+		// SDK normalises it to ms (the worker stamps it in seconds). Absent on a row
+		// that never ran, and on rows written before the SDK projected it -- in both
+		// cases the pass simply shows no duration, which is right: the honest answer
+		// to "how long did it take" is nothing, not the queue wait dressed up as it.
+		var executedTs = Number(item && item.executed);
 		var userTs = isFinite(createdTs) && createdTs > 0 ? createdTs : (isFinite(updatedTs) && updatedTs > 0 ? updatedTs : undefined);
 		var replyTs = isFinite(updatedTs) && updatedTs > 0 ? updatedTs : (isFinite(createdTs) && createdTs > 0 ? createdTs : undefined);
 
@@ -874,6 +880,17 @@ export function mapHistoryListToMessages(list: any[], platform: 'claude' | 'open
 			if (isCompact) okm._compact = true;
 			if (serverItemId !== undefined) okm._serverItemId = serverItemId;
 			if (replyTs !== undefined) okm._ts = replyTs;
+			// How long THIS pass took: from the moment the worker began EXECUTING it to
+			// the moment it resolved. Carried on the reply so the bubble can show it
+			// without its request bubble (a continuation's request is hidden from the
+			// expanded row). Only for an indexing pass: `_tsStart`'s presence is what
+			// scopes the duration to indexing responses in both views.
+			//
+			// Deliberately NOT `created`: that is the enqueue time, so a pass that sat
+			// in the queue for an hour before running would have reported the wait as
+			// though it were the read. No fallback to it either, for the same reason --
+			// a missing `executed` means no duration is shown at all.
+			if (indexFile && isFinite(executedTs) && executedTs > 0) okm._tsStart = executedTs;
 			if (reportedComplete) okm._indexComplete = true;
 			mapped.push(okm);
 		}

package/src/engine/host.ts

@@ -225,6 +225,16 @@ export interface ChatMessage {
 	 *  it is created, then reconciled to the server value on the next history load.
 	 *  Absent while a turn is still pending, so no time shows on a "Thinking" bubble. */
 	_ts?: number;
+	/** Epoch ms the worker began EXECUTING this indexing pass (the SDK's `executed`,
+	 *  not the enqueue time `created`), carried on the ASSISTANT bubble so it can
+	 *  show how long the pass actually took
+	 *  without reaching for its request bubble (a continuation's request is
+	 *  deliberately hidden from the expanded row, so it is not always there).
+	 *
+	 *  Stamped ONLY on an indexing pass's reply. Its presence is therefore also
+	 *  what SCOPES the duration to indexing responses: an ordinary chat answer
+	 *  never carries it, so neither view needs a second test. */
+	_tsStart?: number;
 	// History cache key (`projectId#platform`) this bubble was created under.
 	// Stamped on LOCALLY-created bubbles only (the optimistic user message and
 	// its "Thinking..." placeholder); server-mapped bubbles are identified by

package/src/engine/session.ts

@@ -81,6 +81,13 @@ const INDEX_DISPATCH_CLAIM_MS = 2 * 60 * 1000;
 // that is still alive. Fixed and finite: this must never become a poll.
 const WORKER_PASS_ADOPT_ATTEMPTS = [0, 2000, 6000];
 
+/** How recent a loaded indexing pass has to be to count as evidence that a worker
+ *  chain may still be advancing. Generous on purpose: it only has to outlast the
+ *  gap between two passes of one file, and the cost of being wrong is three queue
+ *  round trips, while the cost of being too tight is a file that reads "Indexed"
+ *  while it is still being read. */
+const RECENT_INDEX_PASS_EVIDENCE_MS = 10 * 60 * 1000;
+
 // awaitIndexingDrained: how often it re-asks the background-indexing queue, and
 // how many consecutive empty answers it needs before believing the chains are
 // over. More than one for the same reason the adopt ladder above looks twice —
@@ -4435,7 +4442,38 @@ export class ChatSession {
 		// full passive ladder for indexing that does not exist.
 		var found = false;
 		this.historyItemPolls.forEach(function (h: any) { if (h && h.kind === 'bg') found = true; });
-		return found;
+		if (found) return true;
+
+		// A chain this client did not START leaves none of the three signals above,
+		// and they are all signals of LOCAL DISPATCH: the bgTaskQueue entry covers
+		// only the pass this page sent and is spliced out as soon as it settles, a
+		// reload clears that array outright, and liveIndexKeys is empty in exactly
+		// the moment the probe just missed. A run begun on the db-files page and
+		// then opened in the chat has none of them, so the ladder never climbed for
+		// it: one probe landing in the gap between pass N resolving and pass N+1
+		// being enqueued marked the file finished, and with no local pass left to
+		// settle, nothing asked again. The row stayed green on a file still being
+		// read.
+		//
+		// The passes themselves are the evidence in that case. Bounded by recency,
+		// because the thing this gate exists to prevent is the climb running on an
+		// idle tab whose indexing finished long ago - and such a chat's newest
+		// indexing pass is hours or days old, so it still does not climb.
+		// Date.now(), NOT nowMs(): `_ts` is a wall-clock epoch (the same clock the
+		// run:: records are stamped with), while nowMs() is performance.now() --
+		// milliseconds since process start. Subtracting the window from that gives a
+		// NEGATIVE cutoff, every epoch `_ts` clears it, and the gate would then be
+		// true for any chat that has ever indexed anything: exactly the always-climb
+		// this gate was added to stop.
+		var cutoff = Date.now() - RECENT_INDEX_PASS_EVIDENCE_MS;
+		var msgs = this.state.messages;
+		for (var mi = msgs.length - 1; mi >= 0; mi--) {
+			var m = msgs[mi];
+			if (!m || !m._indexFile) continue;
+			if (typeof m._ts !== 'number') continue;
+			if (m._ts >= cutoff) return true;
+		}
+		return false;
 	}
 
 	/** Any of these ids still queued or still polled, i.e. surviving work. */

package/src/engine/time.ts

@@ -32,3 +32,32 @@ export function formatChatTimestamp(ms?: number): string {
 		return '';
 	}
 }
+
+/**
+ * "4s", "2m 4s", "1h 2m 4s" — how long one indexing pass took.
+ *
+ * HOURS ARE THE LARGEST UNIT, deliberately: a pass is a single model turn, so a
+ * span of days is not a long read but bad data (a stale `updated` stamp, a clock
+ * skew, a row rewritten much later). Rolling those into hours makes them read as
+ * the anomaly they are — "49h" — instead of dressing them up as a plausible
+ * "2d 1h".
+ *
+ * A zero unit is dropped rather than padded ("1h 4s", not "1h 0m 4s"); seconds
+ * are always shown so the string is never bare.
+ *
+ * Empty string for anything under a second, negative, or non-finite — a pass
+ * cannot take no time, so those are skew or missing data, and callers gate on
+ * the result being truthy exactly as they do for formatChatTimestamp.
+ */
+export function formatDuration(ms?: number): string {
+	if (typeof ms !== 'number' || !isFinite(ms) || ms < 1000) return '';
+	var total = Math.floor(ms / 1000);
+	var h = Math.floor(total / 3600);
+	var m = Math.floor((total % 3600) / 60);
+	var s = total % 60;
+	var out = [];
+	if (h) out.push(h + 'h');
+	if (m) out.push(m + 'm');
+	out.push(s + 's');
+	return out.join(' ');
+}