REST semantic search does not load persisted LanceDB indexes

[GautamSharma99]

The REST server does not reuse the persistent vector index created by the CLI.

repowise init stores embeddings in the repository-local .repowise/lancedb directory. However, repowise serve always initializes a new, empty
InMemoryVectorStore, so semantic searches made through the REST API cannot see the existing embeddings.

This also affects workspace indexing jobs because the job executor always passes the global primary vector store to every repository pipeline.

Exact failure path

1. CLI persists embeddings to LanceDB

The CLI’s vector-store factory prefers a repository-local LanceDB store:

• packages/cli/src/repowise/cli/providers/vector_store.py:9
• LanceDB path: /.repowise/lancedb
• It only falls back to InMemoryVectorStore when LanceDB is unavailable.

During repowise init, that store is passed to the generation pipeline and populated with page and decision embeddings.

2. REST startup discards that persisted index

When the REST server starts, it builds the configured embedder but unconditionally creates a new in-memory store:

• packages/server/src/repowise/server/app.py:193
• packages/server/src/repowise/server/app.py:195

embedder = _build_embedder()
vector_store = InMemoryVectorStore(embedder=embedder)

There is no code here that checks for .repowise/lancedb or opens a configured pgvector backend.

The comment claiming that LanceDB or pgvector can be configured through the environment does not match the implementation; no corresponding
server configuration path exists.

3. Single-repository search queries the empty store

In single-repository mode, workspace_config is None, so semantic search immediately queries the primary in-memory store:

• packages/server/src/repowise/server/routers/search.py:149
• packages/server/src/repowise/server/routers/search.py:153
• packages/server/src/repowise/server/routers/search.py:156

Because this store was created during server startup and contains no vectors, InMemoryVectorStore.search() returns an empty list.

The existing workspace-only LanceDB resolver is never called in this path.

4. Workspace jobs use the wrong vector store

The job executor resolves the correct repository database through session_factory_override, but still takes the vector store from the global
application state:

• packages/server/src/repowise/server/job_executor.py:317
• packages/server/src/repowise/server/job_executor.py:319
• packages/server/src/repowise/server/job_executor.py:395

vector_store = app_state.vector_store

That same store is used for generation, decision embeddings, and deletion of swept page vectors.

Consequences in workspace mode include:

• New embeddings being written to the primary repository’s store or a shared in-memory store.
• Existing per-repository LanceDB indexes remaining stale.
• Embeddings disappearing after a server restart.
• Repository-scoped searches potentially falling back to a shared store containing vectors from another repository.
• Swept page IDs being deleted from the wrong vector store.

Reproduction

1. Run repowise init inside a repository with LanceDB installed.
2. Confirm that .repowise/lancedb exists and contains the wiki_pages table.
3. Stop the CLI process.
4. Run repowise serve from the same repository.
5. Call:

GET /api/search?query=authentication&search_type=semantic

6. Observe that semantic search returns no results even though the persisted LanceDB index contains matching pages.
7. Run the equivalent CLI semantic search and observe that it can use the persisted index.

Expected behavior

• Single-repository REST startup should open the repository’s existing .repowise/lancedb store.
• Semantic search should work immediately after repowise init, without requiring a server-side reindex.
• Workspace jobs should use the vector store belonging to the job’s repository.
• Vector writes, deletes, and searches should remain isolated by repository.
• InMemoryVectorStore should remain an explicit fallback when persistent storage is unavailable.

Proposed implementation direction

Introduce a shared, repository-aware vector-store resolver that can be used by:

• REST application startup for the primary repository.
• Workspace semantic-search routing.
• The background job executor.
• API-managed repositories registered after startup.

For a repository with a .repowise/lancedb directory, the resolver should open LanceDBVectorStore with the configured embedder and cache it by
repository ID. The job executor should resolve the store only after it has loaded the job’s repository metadata.

All cached stores should be closed during application shutdown.

Test gap

The current REST semantic-search test manually inserts vectors into the server’s in-memory store:

• tests/unit/server/test_search.py:21
• tests/unit/server/test_search.py:41

This proves that the endpoint works when its transient store is manually populated, but it does not test the actual repowise init → repowise
serve lifecycle.

[RaghavChamadiya]

Thanks for the detailed write-up @GautamSharma99

1. CLI persists to LanceDB - build_vector_store (cli/providers/vector_store.py:18-25) opens .repowise/lancedb and only falls back to in-memory on ImportError. Correct.
2. REST startup discards it - app.py:194-195 unconditionally builds InMemoryVectorStore. The comment on line 193 ("LanceDB/pgvector configured via env") is aspirational; there's no code that reads env or looks for .repowise/lancedb here. Worth fixing the comment in the same PR so it stops implying a path that doesn't exist.
3. Single-repo search hits the empty store - search.py:154-156 returns primary_vs.search(...) directly when workspace_config is None, and primary_vs is the empty startup store. The LanceDB resolver is only reached in the workspace branch (search.py:161).
4. Job executor uses the global store - job_executor.py:319 sets vector_store = app_state.vector_store while session_factory comes from the override. In workspace mode that writes/deletes embeddings against the primary repo's store, not the job's. Note this resolution happens at line 319, before repo_path/repo_id are known (line 336), which is exactly why it can't pick the right store yet.

The good news is the fix has a strong head start: search_helpers.py already implements the hard parts, LanceDB rehydration, per-repo lazy caching with a lock, and close_workspace_vector_stores on shutdown. Rather than a new resolver, I'd generalize resolve_workspace_vector_store into a repo-aware resolver keyed by repo path + id that all four callers share (startup for the primary repo, single-repo search, workspace search, and the job executor), and reuse the existing cache/close machinery. That matches the issue's proposed direction and avoids a parallel implementation.

Two things to nail down in the implementation:

• Embedder compatibility. The resolver reuses the primary store's embedder (_resolve_embedder). For the single-repo primary that has to be the same embedder used at init time, or the query vectors won't match the persisted ones. Reading it from .repowise/config.yaml (same source init used) is safer than assuming the server's env default. Keep the explicit InMemoryVectorStore fallback when LanceDB is absent.
• Job executor ordering. Resolve the store after the repo metadata is loaded (after line 336, using repo_path), so sync, decision embeddings, and swept-vector deletion all target the job's own LanceDB.

On the test gap: agreed, test_search.py:21/41 manually seeds the in-memory store, so it can't catch this. A lifecycle test (populate .repowise/lancedb as init would, start the app, call search_type=semantic, assert hits) would lock the behavior in. Also worth one workspace-mode assertion that a job's embeddings land in its own store and survive a restart, since that's the more damaging half of this bug.

[GautamSharma99]

Hey @RaghavChamadiya , I have tried to fix that and raised a PR. Can you review it once? PR -> #835