Finding
crates/zetesis/src/repo.rs contains eight public async functions (insert_indexer, get_indexer, list_indexers, get_eligible_indexers, update_indexer_status, update_indexer_caps, delete_indexer, upsert_indexer_categories, restore_degraded_cf_indexers) and no #[cfg(test)] block. The eligibility filter in get_eligible_indexers (enabled = TRUE AND status != 'failed') and the DELETE-then-INSERT sequence in upsert_indexer_categories are entirely untested.
Evidence
crates/zetesis/src/repo.rs:106:
pub async fn get_eligible_indexers(pool: &SqlitePool) -> Result<Vec<IndexerRow>, DbError> {
(No #[cfg(test)] block present in the file.)
Why this matters
get_eligible_indexers is the gate that decides which indexers participate in every search fan-out. A regression in its SQL predicate — e.g. enabled = FALSE rows accidentally selected — silently routes traffic to indexers the operator disabled, defeating the deliberate trust boundary a counter-surveillance operator sets between vetted and untrusted endpoints. upsert_indexer_categories has an ordering dependency (DELETE then INSERT) whose atomicity gap is also invisible without coverage: an interrupted upsert can leave an indexer with no categories, dropping it from results without trace. The prostheke crate covers comparable repo functions with in-memory SQLite tests, establishing a feasible pattern.
Desired correction
Add a #[cfg(test)] module mirroring the pattern in prostheke/repo.rs: spin up sqlite::memory: + MIGRATOR, then test: insert_indexer round-trips, get_eligible_indexers excludes disabled and failed rows, update_indexer_status persists the new value, upsert_indexer_categories replaces categories atomically, and restore_degraded_cf_indexers returns the correct affected-row count.
Done when: get_eligible_indexers filter logic and upsert_indexer_categories replace semantics each have at least one passing test against an in-memory SQLite instance.
Finding
crates/zetesis/src/repo.rscontains eight public async functions (insert_indexer,get_indexer,list_indexers,get_eligible_indexers,update_indexer_status,update_indexer_caps,delete_indexer,upsert_indexer_categories,restore_degraded_cf_indexers) and no#[cfg(test)]block. The eligibility filter inget_eligible_indexers(enabled = TRUE AND status != 'failed') and the DELETE-then-INSERT sequence inupsert_indexer_categoriesare entirely untested.Evidence
crates/zetesis/src/repo.rs:106:(No
#[cfg(test)]block present in the file.)Why this matters
get_eligible_indexersis the gate that decides which indexers participate in every search fan-out. A regression in its SQL predicate — e.g.enabled = FALSErows accidentally selected — silently routes traffic to indexers the operator disabled, defeating the deliberate trust boundary a counter-surveillance operator sets between vetted and untrusted endpoints.upsert_indexer_categorieshas an ordering dependency (DELETE then INSERT) whose atomicity gap is also invisible without coverage: an interrupted upsert can leave an indexer with no categories, dropping it from results without trace. The prostheke crate covers comparable repo functions with in-memory SQLite tests, establishing a feasible pattern.Desired correction
Add a
#[cfg(test)]module mirroring the pattern inprostheke/repo.rs: spin upsqlite::memory:+ MIGRATOR, then test:insert_indexerround-trips,get_eligible_indexersexcludes disabled andfailedrows,update_indexer_statuspersists the new value,upsert_indexer_categoriesreplaces categories atomically, andrestore_degraded_cf_indexersreturns the correct affected-row count.Done when:
get_eligible_indexersfilter logic andupsert_indexer_categoriesreplace semantics each have at least one passing test against an in-memory SQLite instance.