recall repair --execute leaves the vec index empty — semantic search silently degrades to bruteforce, and doctor reports PASS

[edheltzel]

Problem

recall repair --execute embeds missing rows but does not rebuild the sqlite-vec index. It leaves the DB in a state where embeddings is fully populated and the vector index is empty — so semantic search silently runs bruteforce instead of knn, and nothing tells you.

Its own help text says: "Rebuild FTS5 indexes and re-embed missing embeddings". It rebuilds FTS. It does not rebuild vec. A user reasonably reads "repair" as "make the DB healthy."

Reproduction (observed on a live install, 2026-07-15)

$ recall repair --execute
  Embedded 14616 row(s), skipped 7 too-short row(s), 16 failure(s).

$ # embeddings populated, vec index empty:
embeddings:            14616
vec_embeddings_rowids: 0
vec_embeddings_chunks: 0

$ recall doctor
  [PASS] Ollama reachable (semantic search)     <-- reports healthy

$ # MCP search:
Found 10 results (hybrid: FTS5 + embeddings; semantic backend: bruteforce)
                                                                 ^^^^^^^^^^

Then, separately:

$ recall embed reindex
Vector index rebuilt: 14616 entries.     (took ~1 second)

$ # now:
Found 10 results (hybrid: FTS5 + embeddings; semantic backend: knn)

The reindex takes one second. There is no performance reason to omit it from repair.

Why this matters

This is the second failure mode in the same incident (see #240). The recovery path for a dead semantic tier is backfill → and you must independently know to run reindex. Nothing in repair's output, help text, or doctor indicates the vec index is empty. A user who runs the command literally named repair and then checks doctor gets an all-clear on a half-repaired DB — degraded to brute-force, silently.

Compounding: recall doctor has no vec checks at all (#226 item 3), so the gap between "repair finished" and "search is actually healthy" is invisible from every surface.

Proposed fix

• recall repair --execute runs the vec reindex after a successful embedding pass (it costs ~1s on 14.6k rows)
• Add --no-reindex to opt out, mirroring the existing --no-embed
• Report the vec index state in repair's dry-run output alongside FTS (vec index: N entries, M missing) so the plan is visible before --execute
• recall doctor reports vec index row count vs embeddings count and FAILs on mismatch (overlaps Harden vec index: zero-vector guard, index-format version stamp, doctor/stats vec observability #226 item 3)
• Test: after repair --execute on a DB with embeddings and an empty vec index, vec_embeddings_rowids count == embeddings count

Acceptance

1. recall repair --execute on a DB with 0 vec rows leaves the vec index fully populated.
2. recall repair (dry-run) reports the vec index state.
3. Semantic backend reports knn, not bruteforce, after a plain repair --execute.
4. --no-reindex skips it.

Found during the 2026-07-15 confidence investigation. Refs #240, #226, #148.

[edheltzel]

Same bug, second half: repair --execute also skips the embedding marker

Found immediately after filing this issue, on the same live install. It is the same defect class — repair embeds rows but skips every post-embedding step that embed backfill performs — so folding it in here rather than filing a third issue.

Evidence

After recall repair --execute embedded 14,616 rows, the MCP server boots with:

[recall] Embedding marker is stale — run 'recall embed rebackfill' to re-embed at
qwen3-embedding:0.6b (1024d). Semantic search falls back to FTS5 until then.

But the DB is perfectly healthy:

schema_meta embedding keys:  []                                  <-- marker never written
embeddings model spread:     [{ model: "qwen3-embedding:0.6b", dimensions: 1024, c: 14616 }]

All 14,616 rows are uniformly the current model and dimension. Nothing is stale. Semantic search demonstrably works (recall hybrid searches all 14,616; semantic backend: knn).

Why it false-positives

embeddingMarkerStatus (src/lib/embedding-marker.ts:64-80):

const total = ...COUNT(*) FROM embeddings;   // 14616
if (total === 0) return 'absent';
const mismatched = ...WHERE model != ? OR dimensions != ?;   // 0 — rows are fine
if (mismatched > 0) return 'stale';
const marker = readEmbeddingMarker(db);
if (!marker || ...) return 'stale';          // <-- marker is null => 'stale'

Rows match; only the marker is missing — so it reports stale.

Root cause

writeEmbeddingMarker is called from src/commands/embed.ts only — runBackfill (:152, guarded if (success > 0)) and runRebackfill. src/commands/repair.ts never imports or calls it (nor does it reindex vec — the original report above).

$ rg "writeEmbeddingMarker|embedding-marker|reindex|vec" src/commands/repair.ts
(no matches)

So repair --execute performs the embedding work through a path that skips both completion steps backfill does.

Consequence — the recovery command makes recovery look broken

A user recovering from #240 runs the command literally named repair, and lands in a DB that:

1. has a fully-populated embeddings table,
2. has an empty vec index → silently bruteforce, and
3. reports its marker stale → tells them to run rebackfill.

rebackfill re-embeds every row — ~32 minutes for 14,616 on this box — to fix a marker that is a single INSERT OR REPLACE of two key-value rows. The advice is real work, correctly derived, and completely unnecessary.

Worse, the warning claims "Semantic search falls back to FTS5 until then," which was not true here — semantic was working. So the message overstates the failure in one direction while the vec index was genuinely degraded in another, and neither reflected reality.

Revised fix (extends the checklist above)

• repair --execute calls writeEmbeddingMarker(db) after a successful embedding pass — same guard as embed.ts:151 (if (success > 0))
• repair --execute runs the vec reindex (original report)
• Factor the post-embedding completion steps (stamp marker + reindex vec) into one helper both embed backfill and repair call, so a third caller cannot skip half of it again — this is now the second command to diverge from the same sequence
• recall doctor: report marker status; distinguish "marker missing but rows uniform" (cheap INSERT) from "rows genuinely mixed-model" (needs real rebackfill). Today both print the same 32-minute advice
• Consider: when rows are uniform and match the expected model, embeddingMarkerStatus could self-heal the marker rather than report stale — the marker is derived data and the rows are the source of truth

Acceptance (added)

5. After repair --execute on a DB with no marker, schema_meta carries the current model+dims and the MCP server boots with no stale warning.
6. A DB with uniform current-model rows and a missing marker never advises rebackfill.

Refs #240, #226, #107.