fix(cli): repair corrupted LanceDB indexes

[lambertjosh]

Summary

• rebuild a workspace code index when LanceDB reports a referenced .lance data file is missing
• stop running table optimization during every store initialization
• use LanceDB’s default retention window when cleanup is intentionally requested

Why

Code indexes are derived data and can be regenerated from the workspace, but the existing recovery loop repeatedly reopened the same poisoned store. Recent schema recreation and shared worktree readers can leave a reader holding a snapshot whose data files were removed. Restricting self-repair to LanceDB’s missing-object error makes rebuilding safer than leaving indexing permanently unavailable, while unrelated initialization failures remain non-destructive.

[kilo-code-bot]

SUGGESTION: Consider noting the LanceDB version this error text is matched against

missing() keys off LanceDB's exact error wording (Object at location ... .lance not found:), which is the only signal available since lancedb doesn't expose structured error codes — the gating is reasonable. The risk is that a future @lancedb/lancedb upgrade rewords this message, at which point self-repair silently stops triggering and init falls back to throwing. A short comment pinning the matched format to the current dependency version (0.26.x) would tell future upgraders to re-verify this string.

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

SUGGESTION: With startup optimization removed, version cleanup no longer has a periodic caller

Removing the this.optimizeTable() calls from init() makes sense — the old cleanupOlderThan: new Date() could delete data files that concurrent readers still referenced. But optimizeTable() is now only called from clearCollection(), and every upsert/delete creates a new LanceDB on-disk version, so long-lived workspaces that never clear the collection will accumulate versions unboundedly (the doc comment above still says "Should be called periodically to prevent unbounded disk space growth"). Since table.optimize() with default retention (~7 days) is far safer for concurrent readers than the old call, it may be worth keeping a throttled optimize (e.g. after a successful init, or driven by the orchestrator) — or, if running only on clear is the intended design, updating the doc comment to say so.

---

Reply with @kilocode-bot fix it to have Kilo Code address this issue.

[kilo-code-bot]

Code Review Summary

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	2

The self-repair design is sound: repair is gated on LanceDB's specific missing-data-file error, retried exactly once (init(false) prevents loops), and the orchestrator treats the returned true as a fresh store and runs a full re-scan. Baseline readers via openExisting() correctly get no repair path, so a worktree reader can't delete shared data. Removing the fire-and-forget startup optimizeTable() with cleanupOlderThan: new Date() eliminates the root cause of readers losing their snapshots, and the new table.optimize() default retention is much safer. Both findings are minor follow-ups, not blockers. No memory leaks introduced — no new listeners, timers, or retained references.

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
packages/kilo-indexing/src/indexing/vector-store/lancedb-vector-store.ts	285	Error-message string match in missing() isn't pinned to a LanceDB version; a dependency upgrade rewording the message silently disables self-repair
packages/kilo-indexing/src/indexing/vector-store/lancedb-vector-store.ts	596	Startup optimization removal leaves version cleanup without a periodic caller — LanceDB versions accumulate unboundedly between clearCollection() calls

Files Reviewed (3 files)

• .changeset/repair-missing-lance-files.md - 0 issues
• packages/kilo-indexing/src/indexing/vector-store/lancedb-vector-store.ts - 2 issues
• packages/kilo-indexing/test/kilocode/indexing/vector-store/lancedb-vector-store.test.ts - 0 issues

Fix these issues in Kilo Cloud

---

_{Reviewed by kimi-k3 · Input: 58.3K · Output: 13.3K · Cached: 411.6K}

_{Review guidance: REVIEW.md from base branch main}