Skip to content

chore(deps): bump LocalAGI for collection rehydrate-on-init-failure fix#9721

Merged
mudler merged 1 commit into
masterfrom
chore/bump-localagi-rehydrate
May 8, 2026
Merged

chore(deps): bump LocalAGI for collection rehydrate-on-init-failure fix#9721
mudler merged 1 commit into
masterfrom
chore/bump-localagi-rehydrate

Conversation

@localai-bot
Copy link
Copy Markdown
Collaborator

Summary

Bumps github.com/mudler/LocalAGI from v0.0.0-20260507074708-c1a12317930d to v0.0.0-20260508125235-37810d918a87 to pick up the in-process collections rehydrate-on-init-failure fix that just merged into LocalAGI's main.

Why

When the embedding model is briefly unreachable while LocalAI is starting up (e.g. a NATS hiccup to the node hosting the embedding model), the agent pool's webui/collections backend used to silently drop every on-disk collection from its in-memory map. Subsequent operations against those collections returned "collection not found" indefinitely — even after the embedding service recovered — because nothing ever retried. The collection's metadata + data still existed on disk and in the vector DB, but the user could no longer reach it without restarting LocalAI.

With the bumped LocalAGI:

  • Boot loop registers a nil placeholder for collections whose engine wrapper failed to construct, instead of dropping them silently.
  • A new lookup helper used by every operation (Upload, Search, ListEntries, …) detects placeholders and rehydrates lazily on first access. Once the embedding service is reachable again, the next request transparently brings the collection back.

Scope of this change

Pure dependency bump. go mod tidy brought in a few transitive indirects from LocalAGI's deps (cobra, pflag, gofiber/template, …) that were already pulled by LocalAGI but not previously surfaced in LocalAI's go.mod. No code changes in LocalAI itself.

Not addressed here

The deeper issue is in mudler/localrecall's rag.NewPersistentPostgresCollection: the constructor probes the embedding model at engine-construction time, so even read-only paths against existing collections require the embedding service to be available. That's a separate fix worth pursuing in LocalRecall — let it construct without a probe and have the probe happen lazily on first write/search instead.

Test plan

  • go build ./core/services/agentpool/... (passes locally)
  • Integration: in a deployment where the embedding model briefly times out at LocalAI startup, confirm existing collections become reachable again on first request after the embedding service recovers (no need to restart LocalAI)

🤖 Generated with Claude Code

Picks up mudler/LocalAGI#? (commit 941ac52, merged into main):
in-process collections backend now registers a placeholder for every
on-disk collection at startup — even when the engine wrapper fails to
construct (typically because the embedding model is briefly
unreachable) — and rehydrates lazily on first access. Previously a
transient outage at LocalAI boot silently dropped every existing
collection from the agent pool's in-memory map; users saw "collection
not found" indefinitely until LocalAI was restarted, even after the
embedding service recovered. With this bump the next request to the
collection rehydrates it transparently.

Does not address the deeper LocalRecall issue where
NewPersistentPostgresCollection probes the embedding model at engine
construction even for read-only paths — that needs a separate fix in
mudler/localrecall.
@mudler mudler merged commit 6070aaf into master May 8, 2026
50 checks passed
@mudler mudler deleted the chore/bump-localagi-rehydrate branch May 8, 2026 14:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants