bunnyquery 1.10.0 → 1.10.2

package/package.json

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

package/src/engine/indexing_groups.ts

@@ -36,6 +36,17 @@
  * loaded (`mayHaveOlder`), and it is the same event that already re-derives
  * `runKey` — so the view treats it as a new row either way.
  *
+ * One row per FILE, not per run. A file indexed and later indexed again (a
+ * re-upload, an explicit Reindex, a retry after a failure) has several RUNS in
+ * the transcript, each opened by its own "A new file has just been uploaded"
+ * pass. They are attributed as separate groups (mixing their passes would let an
+ * old failure be painted over by a new success, or a new run inherit an old
+ * stop), but only the NEWEST run of a file is rendered once the older ones have
+ * settled. Two green "Indexed" rows for one file read as a duplicate, not as
+ * history, and a superseded run's verdict is not the file's state. An older run
+ * that is still working stays visible until it settles, so a double dispatch is
+ * never hidden while both chains are live and its Stop button stays reachable.
+ *
  * The group deliberately reports no authoritative pass TOTAL. History is paged
  * newest-first, so any total computed from loaded messages is a lower bound that
  * a later scroll-up would contradict. It reports STATE (indexing / indexed /
@@ -75,12 +86,13 @@ export type IndexingGroup = {
 	 *  surprised out of. */
 	key: string;
 	/** Identity of this ROW: one indexing RUN of that file. A file indexed on
-	 *  Monday and re-indexed on Wednesday is two runs, and collapsing them into
-	 *  one row erased Monday's from Monday's place in the conversation, claimed
-	 *  its passes for Wednesday, and let Monday's failure be overwritten by
-	 *  Wednesday's success. Named after the run's FIRST loaded pass (see where it
-	 *  is assigned below), so passes appended to the run and other runs appearing
-	 *  on either side of it never rename a row already on screen.
+	 *  Monday and re-indexed on Wednesday is two runs, and merging them into one
+	 *  group claimed Monday's passes for Wednesday and let Monday's failure be
+	 *  overwritten by Wednesday's success. They stay separate groups; what the
+	 *  view gets is only the newest of them once the rest have settled (see the
+	 *  file docstring). Named after the run's FIRST loaded pass (see where it is
+	 *  assigned below), so passes appended to the run and other runs appearing on
+	 *  either side of it never rename a row already on screen.
 	 *
 	 *  This is the RENDER key, and only that. It is renamed when the run's true
 	 *  first pass finally loads — routine while a worker-driven chain is running,
@@ -395,6 +407,48 @@ function isHiddenPass(m: ChatMessage): boolean {
  * Messages that are not background-indexing pass through untouched, at their
  * original positions and with their original indices.
  */
+/**
+ * A loaded group reads its state off its newest loaded pass, and for a run the WORKER
+ * ended (three failed retries, a stale grant, a cap-out) that pass looks settled: the
+ * model answered normally, the failure happened after. The run:: record is the only
+ * thing that knows, and until now it was consulted for record-only stubs alone, so
+ * the chat row said "Indexed", the files page took that as a verdict and painted the
+ * badge green over the record's "error". The record's terminal verdict is laid over
+ * the group when it describes THIS run (started no later than the newest loaded pass)
+ * and is newer than that pass; visible work and a live queue hit still outrank it.
+ */
+function overlayRunRecordVerdict(
+	grp: IndexingGroup,
+	rec: RunStubInfo,
+	liveIndexKeys: { [key: string]: boolean },
+): void {
+	if (!grp.members.length || grp.status === 'active' || grp.cancelling) return;
+	if (rec.status === 'working' || typeof rec.started !== 'number') return;
+	if (liveIndexKeys[grp.key] || liveIndexKeys[canonIndexKey(grp.key)]) return;
+	var firstTs = grp.members[0].msg._ts;
+	var lastTs = grp.members[grp.members.length - 1].msg._ts;
+	if (typeof lastTs !== 'number' || typeof firstTs !== 'number') return;
+	// a record that started after the newest loaded pass is a LATER run, not this one
+	if (rec.started > lastTs) return;
+	var when = typeof rec.finished === 'number' ? rec.finished : undefined;
+	if (when === undefined) return;
+	// a record that ENDED before this run began describes a previous run
+	if (when < firstTs) return;
+	// the record's verdict must be at least as new as the pass it would override
+	// (a few seconds of slack: the worker closes the record right after the pass lands)
+	if (when < lastTs - 5000) return;
+	if (rec.status === 'error' || rec.status === 'cancelled') {
+		grp.status = rec.status;
+	} else if (rec.status === 'done') {
+		grp.status = 'done';
+	} else {
+		return;
+	}
+	grp.finished = true;
+	grp.resolving = false;
+	grp.resolvingReason = undefined;
+}
+
 export function buildChatDisplayList(
 	messages: ChatMessage[],
 	opts?: BuildDisplayListOptions,
@@ -812,6 +866,28 @@ export function buildChatDisplayList(
 		}
 	}
 
+	// --- superseded runs -------------------------------------------------------
+	// Every run of a file but its newest is history the newest run replaced: the
+	// file's state is the newest run's, and a second "Indexed" row for the same
+	// file reads as a duplicate (reported as exactly that, for files re-indexed
+	// during testing). Such a run keeps its group (its passes stay attributed to
+	// it, never demoted to loose "Indexing: ..." bubbles) but draws no row.
+	//
+	// ONLY once it has settled. An older run that is still working, or still
+	// stopping, is live work the user can see the effects of and may want to stop,
+	// and hiding it would also hide a double dispatch (two chains reading one file)
+	// for as long as both ran. Runs open in walk order, and the walk is request
+	// creation order, so the last run of a key is its newest.
+	var superseded: { [runId: string]: boolean } = {};
+	for (var sk in runsOfKey) {
+		var srs = runsOfKey[sk];
+		for (var sri = 0; sri < srs.length - 1; sri++) {
+			var sgp = groups[srs[sri]];
+			if (!sgp || sgp.status === 'active' || sgp.cancelling) continue;
+			superseded[srs[sri]] = true;
+		}
+	}
+
 	// --- durable run:: stubs ---------------------------------------------------
 	// A run record whose passes are not among the loaded messages still deserves
 	// a row: on a fresh open the bg history is deferred, and a run older than the
@@ -991,6 +1067,7 @@ export function buildChatDisplayList(
 			// record-only to loaded-passes keeps its DOM node and its position.
 			tg.runKey = 'run:' + (tg.path || tg.key) + '#' + trec.started;
 			stubList.push({ started: trec.started, group: tg });
+			overlayRunRecordVerdict(tg, trec, liveIndexKeys);
 		}
 	}
 	stubList.sort(function (a, b) { return a.started - b.started; });
@@ -1015,7 +1092,9 @@ export function buildChatDisplayList(
 		// Every other member of the run is represented by the row at the anchor —
 		// unless the row is timestamp-anchored (incomplete run with a run::
 		// record), in which case the flush above already emitted it.
-		if (groups[r].anchorIndex === j && !suppressAnchor[r]) {
+		// ...or the run is superseded, in which case nothing is emitted for it at
+		// all: its members are represented by the newer run's row.
+		if (groups[r].anchorIndex === j && !suppressAnchor[r] && !superseded[r]) {
 			out.push({ kind: 'indexing', group: groups[r], index: j });
 		}
 	}

package/src/engine/link_markup.ts

@@ -77,8 +77,15 @@ export function renderInlineLinkHtml(link: RenderableInlineLink, opts?: InlineLi
 	if (unavailable) cls.push('is-unavailable');
 	if (preview) cls.push('is-image-preview');
 
-	var labelText = (unavailable ? INLINE_LINK_UNAVAILABLE_GLYPH : INLINE_LINK_GLYPH) + ' ' + link.label
-		+ (unavailable ? INLINE_LINK_UNAVAILABLE_SUFFIX : refreshing ? ' (fetching...)' : '');
+	// The glyph is its own element so chat.css can make it an atomic inline: an
+	// underline propagates into every in-flow inline descendant of the anchor and
+	// nothing inside can cancel it, so the ↗ was underlined along with the label
+	// whenever the chip was. The spacing that used to be a literal space is a
+	// margin on the span for the same reason (a space is decorated too).
+	var glyphHtml = '<span class="bq-link-glyph" translate="no">'
+		+ (unavailable ? INLINE_LINK_UNAVAILABLE_GLYPH : INLINE_LINK_GLYPH) + '</span>';
+	var labelHtml = glyphHtml + escapeInlineHtml(link.label
+		+ (unavailable ? INLINE_LINK_UNAVAILABLE_SUFFIX : refreshing ? ' (fetching...)' : ''));
 	var attrs = ['class="' + cls.join(' ') + '"'];
 	// NO href when the file is unavailable. That is what disables the click:
 	// an anchor with no href does not navigate, is not a tab stop and takes the
@@ -99,7 +106,7 @@ export function renderInlineLinkHtml(link: RenderableInlineLink, opts?: InlineLi
 	if (link.remotePath) attrs.push('data-bq-remote-path="' + escapeInlineHtml(link.remotePath) + '"');
 	if (link.fullLabel) attrs.push('data-bq-full-label="' + escapeInlineHtml(link.fullLabel) + '"');
 
-	if (!preview) return '<a ' + attrs.join(' ') + '>' + escapeInlineHtml(labelText) + '</a>';
+	if (!preview) return '<a ' + attrs.join(' ') + '>' + labelHtml + '</a>';
 
 	// NO src attribute. A stored file always classifies as the _expired_.url
 	// placeholder until something mints a real url, so a src written here would be
@@ -127,6 +134,6 @@ export function renderInlineLinkHtml(link: RenderableInlineLink, opts?: InlineLi
 		// dot trail, never the jumping bunny. CSS hides it the moment the <img>
 		// gains a src, so no JS removes DOM and nothing re-parses.
 		'<span class="bq-loader" data-bq-img-loader="1"></span>' +
-		'<span class="bq-img-preview-caption" translate="no">' + escapeInlineHtml(labelText) + '</span>' +
+		'<span class="bq-img-preview-caption" translate="no">' + labelHtml + '</span>' +
 		'</a>';
 }

package/styles/chat.css

@@ -419,6 +419,26 @@
     text-decoration: none;
     cursor: default;
 }
+/* An assistant bubble's chips are emitted by renderInlineLinkHtml INSIDE the
+   v-html `.bq-md` block, where `.bq-md a` below (underline at rest, none on
+   hover -- the prose-link convention) is (0,1,1) and outranks .bq-link-button
+   at (0,1,0). So those chips rendered the exact inverse of the rule above:
+   underlined at rest, underline gone under the pointer, while the same chip on
+   a user bubble (outside .bq-md) behaved. Restate the chip rule at a
+   specificity that wins inside .bq-md, the dead chip included. */
+.bq-md a.bq-link-button { text-decoration: none; }
+.bq-md a.bq-link-button:hover { text-decoration: underline; }
+.bq-md a.bq-link-button.is-unavailable:hover { text-decoration: none; }
+/* The ↗ / ✕ glyph is never underlined, at rest or on hover. Underlines propagate
+   into every in-flow inline descendant and a descendant cannot cancel them, so
+   `text-decoration: none` on the glyph alone does nothing; an atomic inline
+   (inline-block) is exempt, and the spacing is a margin so no decorated space
+   character carries the line up to the glyph. */
+.bq-link-glyph {
+    display: inline-block;
+    text-decoration: none;
+    margin-right: 0.3em;
+}
 
 /* ---- inline image previews ----------------------------------------------*/
 /* The anchor IS the preview: picture on top, the ordinary chip underneath as a