94a4d2db · zzmq.dev@gmail.com/zz
Commit
94a4d2db120434ebed0dd038ee4b798c4795da35
Clean up ladder_index/repo_tracking on repo delete, not just repos/repo_roles deleteRepoRow only ever cleared repo_roles and repos -- ladder_index (keyed by artifacts_name, not slug, since that's what a DO actually has on hand when writing a rung) and repo_tracking were never touched, so a deleted repo's search-index entries became permanent orphans: dead weight ladder_index's FTS5 MATCH has to scan past on every future search, never cleaned up since nothing ever looked for them. Confirmed live in the real deployment: 90 of 98 rows in ladder_index were exactly this, left behind by repos deleted over the course of one long session's testing. One-time remediation run directly against D1 to clear the existing orphans (down to 11, the real current repos); deleteRepoRow itself now takes artifactsName and clears both tables going forward, at both call sites (a plain repo delete and the recursive shard-tree cleanup). Measured search latency before/after (145ms / 330ms, both fast) -- this wasn't single-handedly causing multi-second slowness on its own at only ~100 rows, but it's unbounded growth with no cap otherwise, and worth having fixed regardless.
Troy Howard <thoward37@gmail.com> -- 2026-10-13T10:22:29.000Z