Files
Ettore Di Giacinto 37810d918a fix(collections): rehydrate in-process collections lazily after init failure (#468)
When NewInProcessBackend boots, it iterates every on-disk collection and
calls newVectorEngine to construct its engine wrapper. For the postgres
engine that constructor performs a "test embedding" probe that requires
the embedding model to be reachable. If the embedding service is briefly
unavailable at boot — e.g. the node hosting the embedding model has
temporary NATS connectivity issues — the construction fails and the
collection is silently dropped from the in-memory map. Subsequent
operations against that collection (Upload / Search / ListEntries / …)
all return "collection not found" indefinitely, even after the embedding
service comes back, because nothing ever retries.

Worse, the collection still exists on disk (its JSON sidecar) and its
data still exists in the vector DB (e.g. the per-collection
documents_col_<uuid> table in PostgreSQL). From the user's perspective
their collection has silently disappeared.

Two changes:

1. NewInProcessBackend always registers every on-disk collection in
   state.Collections — even when newVectorEngine returns nil. A nil
   entry is a placeholder meaning "known on disk, not yet loaded".

2. backendInProcess.lookup centralises the cache read for every
   operation. If the cache holds a placeholder, it retries
   newVectorEngine now, under the write lock. So as soon as the
   embedding service is reachable again, the next request to the
   collection will rehydrate it transparently. If init still fails or
   the collection isn't on disk at all, lookup returns (nil, false)
   and the operation surfaces "collection not found" as before.

The state.EnsureCollection callback used by the internal RAG provider
already handled the placeholder case (it re-inits whenever the cache
entry is missing or nil), so it needs no change.

This does not address the underlying probe-and-cache pattern in
LocalRecall's NewPersistentPostgresCollection — read-only operations
on existing collections still require an embedding probe at engine
construction. That is a separate, deeper fix worth pursuing in
LocalRecall directly.
2026-05-08 14:52:35 +02:00
..
2026-03-21 00:46:41 +00:00
2026-03-21 00:46:41 +00:00