mirror of
https://github.com/mudler/LocalAGI.git
synced 2026-07-23 18:55:52 -04:00
37810d918a
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.