## 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.

```text
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:

```python
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:

```python
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:

```python
# 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:

```bash
# 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/pst_4QrFyZ16ZGKWERQD_R8hIQ