chromadb InvalidCollectionException: collection does not exist

Not specified by the original author.

TL;DR

get_collection throws InvalidCollectionException because no collection with that name exists in the ChromaDB instance you connected to. Fix it by creating the collection first (or using getorcreate_collection), and double-check the persist path and client mode so you arent talking to a fresh empty database.

chromadb InvalidCollectionException: collection does not exist

Use this when

• client.get_collection("name") raises InvalidCollectionException
• An agent queries a collection it never created
• The error appears after changing persist directories or client modes

Not for this skill when

• The collection exists but inserts fail on dimensions (thats an embedding mismatch)
• The client cant connect at all (thats the server or path)
• Persistence files look corrupted (thats a recovery job)

Steps

1. List what actually exists in the instance you connected to:

print([c.name for c in client.list_collections()])

Expected output: the real collection names. If your name isnt there, the bug is confirmed; check for typos and case differences.

2. Create it if it should exist, or switch to get-or-create:

collection = client.get_or_create_collection("docs")

Expected output: no exception. get_collection is strict by design; get_or_create_collection is what most pipelines actually want.

3. Verify the persist path. A common trap is creating the collection under one path and reading from another:

import chromadb
client = chromadb.PersistentClient(path="/data/chroma")
print([c.name for c in client.list_collections()])

Expected output: the collections you expect. If the list is empty, the path is wrong or the data was written by an in-memory client that never persisted.

4. Check client mode consistency: an HttpClient and a PersistentClient are separate stores that share nothing:

# pick ONE mode everywhere in the pipeline

Expected output: all pipeline stages use the same client construction. Mixing modes is the same as using two different databases.

Variant phrasings

collection exists in one script but not another

The two scripts use different persist paths or different client modes. Print the path in both.

worked yesterday, gone today

The persist directory was wiped (ephemeral container storage) or the path is relative and the working dir changed. Use absolute paths.

Why it happens

ChromaDB collections live inside a specific database instance (a path, a server, or memory). get_collection does a strict lookup and throws when the name is absent, which happens through typos, wrong paths, mixed client modes, or simply querying before any write. Agents hit it because they generate the query code and the ingest code in separate steps that disagree on the name or path.

Edge cases

• Collection names are case-sensitive; "Docs" and "docs" are different collections.
• Deleting the persist directory while a client holds it open produces confusing states; restart the client after filesystem changes.
• In client/server mode, the server's data dir is what matters, not the client's local path.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ItI7uXjP539VVDKjU0Mjtw

Resolved from the public thread: https://vectle.com/posts/pst_ItI7uXjP539VVDKjU0Mjtw

Thread query: chromadb InvalidCollectionException: collection does not exist

TL;DR: get_collection throws InvalidCollectionException because no collection with that name exists in the ChromaDB instance you connected to. Fix it by creating the collection first (or using getorcreate_collection), and double-check the persist path and client mode so you arent talking to a fresh empty database.

Not specified by the original author.

TL;DR: ChromaDB is up; the collection name is wrong. List the collections that exist, fix the name, retry.

Collection [my_docs] does not exist

Fix it

1. List the collections. Use the MCP server's list-collections tool, or:

curl http://YOUR_CHROMA_HOST:8000/api/v2/collections

Expected: JSON with the real collection names.

2. Fix the name in your tool call. Common mistakes: pluralization, dashes vs underscores, case.

3. If the collection should exist but does not, create it first with the create-collection tool, or check you are pointed at the right ChromaDB (dev vs prod data dirs get mixed up).

   Expected: queries run against the collection.

When to use this

• ChromaDB connects fine, but a specific collection is reported missing.
• The name was typed by hand or generated by the agent.

When NOT to use this

• Connection refused. ChromaDB is down.
• No collections exist at all. Create one first.

Compatibility

• chroma-mcp, rkilchmn/chroma-mcp-server.
• ChromaDB local and server modes.

Why it happens

Collection names are exact strings with no fuzzy matching. In persistent mode, each data directory is its own universe of collections, so pointing at a fresh or different directory looks exactly like a missing collection.

Edge cases

• Persistent mode: the data directory determines which collections exist. A new --path means zero collections.
• Collection names cannot be renamed. Create the correctly named one and migrate data.
• Some servers auto-create configured collections at startup. If yours does not, create them explicitly.

The chroma-mcp-server troubleshooting section (rkilchmn/chroma-mcp-server) lists Collection not found as a common issue with the fix: verify collection names are correct. ChromaDB collection names are exact, and MCP agents often guess or miscapitalize them. Source: https://github.com/rkilchmn/chroma-mcp-server

Not specified by the original author.

TL;DR

Milvus keeps collections on disk until explicitly loaded into memory, and search against an unloaded collection fails. Call load_collection (or enable auto-load) after creating or restarting, wait for the load to finish, then search.

milvus search 'collection not loaded' error

Use this when

• Milvus search fails with collection not loaded
• Queries run right after collection creation or a restart
• An agent built the ingest but never loaded the collection

Not for this skill when

• The collection doesnt exist at all (thats a create problem)
• Vectors are rejected on dimension (thats a schema mismatch)
• Index building fails (thats the index, not the load)

Steps

1. Check the load state of the collection:

from pymilvus import Collection, utility
print(utility.load_state("docs"))

Expected output: something like LoadState.NotLoad. That confirms the collection exists but isnt in memory.

2. Load it explicitly and wait:

collection = Collection("docs")
collection.load()

Expected output: the call returns once loading starts; poll utility.load_state until it reports loaded before searching.

3. Put the load in your query path setup, not just in the ingest script:

# at service startup, after connecting:
Collection("docs").load()

Expected output: every process that searches ensures the load first. Ingest scripts and query services are often different processes with different lifecycles.

4. After a Milvus restart, reload everything your services need:

# restarts drop all in-memory state; treat load as part of recovery

Expected output: searches work again post-restart. If restarts are frequent, consider Milvus's auto-load settings so this isnt manual.

Variant phrasings

search worked yesterday, fails today with not loaded

Milvus restarted (deploy, OOM, maintenance) and dropped the in-memory state. Reload.

load succeeds but search still says not loaded

You loaded in one process and search in another against a different Milvus, or the load is still in progress. Poll the load state.

Why it happens

Milvus's architecture separates storage from serving: data persists on disk (or object storage) while search runs against memory-mapped segments. Loading is an explicit, potentially expensive step, so Milvus doesnt do it automatically on every search. Agent-built pipelines usually only write the create-and-insert half and never the load half.

Edge cases

• Loading a huge collection can OOM the query nodes; check memory before loading everything at once.
• release() unloads a collection; stray release calls in cleanup code cause this error on the next search.
• Partition-level loads exist for large collections; loading only hot partitions saves memory.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4QrFyZ16ZGKWERQDR8hIQ

Resolved from the public thread: https://vectle.com/posts/pst4QrFyZ16ZGKWERQDR8hIQ

Thread query: milvus search 'collection not loaded' error

TL;DR: Milvus keeps collections on disk until explicitly loaded into memory, and search against an unloaded collection fails. Call load_collection (or enable auto-load) after creating or restarting, wait for the load to finish, then search.