Vector search silently degrades when configured index has no ready manifest rows

[phernandez]

Finding (Milvus tire-kick session, #1235)

When semantic_vector_index points at an index that holds no ready manifest rows for the
project, search silently degrades with no signal, in both directions:

• pgvector-indexed project, config flipped to milvus, before bm reindex --embeddings:
  --vector returns "No results found"; --hybrid quietly serves FTS-only results.
• The reverse (milvus-owned manifest, pgvector configured): identical silent degradation.

_hydrate_vector_matches filters on vector_index = <configured>, so zero rows hydrate.
The user gets no warning that semantic recall is gone — hybrid results still look
plausible because FTS carries them.

Proposal

When a vector/hybrid query finds the configured index has zero ready manifest rows for the
project (a cheap count), surface it: a logged warning at minimum, ideally a response-level
notice ("semantic index 'milvus' has no ready vectors for this project — run
bm reindex --embeddings"). Fail-closed hydration itself is correct and should not change.

[claude]

Claude finished @phernandez's task in 45s —— View job

---

Triage

Type: Bug (bug label applied)

Component: Search / semantic vector index (repository layer — src/basic_memory/repository/search_repository_base.py, _hydrate_vector_matches and related manifest-count paths). Not cloud-specific: the failure mode reproduces with either pgvector or milvus as the configured semantic_vector_index, so no cloud label applied.

Priority: Medium. Nothing is corrupted and fail-closed hydration is working as intended — but silent loss of semantic recall (with hybrid results still looking plausible via FTS) is a real usability/trust gap for anyone who reconfigures their vector index without immediately re-running bm reindex --embeddings.

Complexity: Simple–Medium. The fix is localized to the query path: a cheap COUNT of ready manifest rows for the configured index/project before/alongside the existing hydration query, then surfacing a warning (log at minimum, response-level notice ideally) when that count is zero. No schema or write-path changes — read-only, so it fits the derived-state consistency model without needing new locking.

Reproduction: Already well specified in the issue (both directions: pgvector→milvus and milvus→pgvector, before running bm reindex --embeddings) — no additional repro steps needed.

Duplicates: None found. Related but distinct: #1235 (parent Milvus tire-kick session), #1237 (reindex --embeddings reports success when every entity fails to embed), #1238 (Milvus + local-Postgres doc gaps) — all from the same session, none overlapping this specific silent-degradation finding.

[phernandez]

Triaged: documentation, not a behavior change. Flipping semantic_vector_index requires bm reindex --embeddings by design — the fail-closed hydration doing exactly its job. The requirement and the degraded intermediate state (vector empty, hybrid FTS-only until reindex) will be documented via #1238, which already carries this as a bullet. Consolidating there.