Bug: Search returns 0 results for cubes with fewer memories despite valid Qdrant data

[r4brr9kjvj-cmd]

Description

The /product/search API returns 0 results for certain memory cubes despite the data being correctly stored in both Qdrant and Neo4j. The issue specifically affects cubes with smaller memory counts while cubes with larger counts work correctly.

Environment

• MemOS version: 1.0.1 (Docker)
• Embedding model: qwen3-embedding:8b (4096-dim)
• Vector DB: Qdrant v1.15.3
• Graph DB: Neo4j 5.26.6
• Deployment: Docker Compose on macOS (M4 Pro)

Steps to Reproduce

1. Create multiple memory cubes with varying sizes
2. Store memories in each cube via /product/add
3. Search each cube via /product/search with correct parameters

Expected Behavior

All cubes with stored memories should return relevant results.

Actual Behavior

Cube	Memories (Neo4j)	Memories (Qdrant)	Search Results
hermes-shared	2,911	2,911	✓ 3 results
hermes-mac-mini-private	29	27	✓ 3 results
hermes-ubuntu-private	93	93	✗ 0 results
hermes-worklab-private	64	64	✗ 0 results

Investigation Findings

1. Data integrity verified

All data exists in both Neo4j and Qdrant with correct metadata:

Neo4j memory types:
  hermes-shared: 2482 LongTermMemory + 429 UserMemory
  hermes-ubuntu-private: 83 LongTermMemory + 10 UserMemory
  hermes-worklab-private: 3 LongTermMemory + 61 UserMemory
  hermes-mac-mini-private: 21 LongTermMemory + 8 UserMemory

Qdrant: 3098 total points, all with 4096-dim vectors and correct user_name filters.

2. Direct Qdrant vector search works for ALL cubes

Direct vector search via Qdrant REST API returns correct results for ALL cubes, including the affected ones. The vectors and metadata are intact.

3. Search pipeline analysis

The search flow in searcher.py → _retrieve_paths() runs these in parallel:

• _retrieve_from_working_memory → Neo4j query for WorkingMemory (0 entries exist for any cube)
• _retrieve_from_long_term_and_user → Should do vector search for LongTermMemory/UserMemory
• _retrieve_from_internet → Internet search
• _retrieve_from_keyword → Fulltext search

4. Critical finding: _vector_recall method missing

In recall.py, the GraphMemoryRetriever class references self._vector_recall at lines 144, 212, and 232, but no such method exists on the class. Only _vector_recall_ORIGINAL is defined (line 370):

# Line 144 - calls self._vector_recall
future_vector = executor.submit(
    self._vector_recall,  # ← This method doesn't exist!
    query_embedding or [],
    memory_scope,
    top_k,
    ...
)

# Line 370 - only this method exists
def _vector_recall_ORIGINAL(self, query_embedding, memory_scope, ...):
    # ... actual vector search implementation

Verified at runtime:

>>> from memos.memories.textual.tree_text_memory.retrieve.recall import GraphMemoryRetriever
>>> hasattr(GraphMemoryRetriever, '_vector_recall')
False
>>> hasattr(GraphMemoryRetriever, '_vector_recall_ORIGINAL')
True

5. API Request Used

POST /product/search
{
    "query": "ubuntu infrastructure",
    "user_id": "hermes-user",
    "readable_cube_ids": ["hermes-ubuntu-private"],
    "mode": "fast",
    "top_k": 6,
    "relativity": 0.35,
    "dedup": "mmr",
    "include_preference": false,
    "search_tool_memory": false,
    "include_skill_memory": false
}

Response for affected cubes: {"data": {"text_mem": []}}

Possible Root Cause

The _vector_recall method is referenced but undefined. The _vector_recall_ORIGINAL method contains the actual vector search implementation. Either:

1. _vector_recall was renamed to _vector_recall_ORIGINAL and the references weren't updated
2. A wrapper/decorator that was supposed to create _vector_recall from _vector_recall_ORIGINAL is not working
3. There's a silent exception handling that masks the AttributeError for some code paths

Suggested Fix

Rename _vector_recall_ORIGINAL back to _vector_recall, or update all references (lines 144, 212, 232) to use _vector_recall_ORIGINAL.

[r4brr9kjvj-cmd]

Update: Root Cause Found and Fixed

The issue was NOT the _vector_recall_ORIGINAL naming. The actual root cause is:

Missing status field in Qdrant payload

The search pipeline filters by status=activated when querying Qdrant. However, after reindexing memories (e.g., after an embedding model upgrade), the status field was missing from the Qdrant point payloads.

Evidence:

Cube	Total Points	With status=activated
hermes-ubuntu-private	93	0
hermes-worklab-private	64	0
hermes-shared	2,911	242
hermes-mac-mini-private	30	14

hermes-shared "worked" because it had 242 points with status=activated (from memories added through the normal API, not the reindex script). The smaller cubes had 0 points with the status field because ALL their memories were reindexed without it.

The filter that causes the issue

In neo4j_community.py, search_by_embedding() builds this Qdrant filter:

vec_filter = {
    "memory_type": scope,           # e.g., "LongTermMemory"
    "status": "activated",          # ← THIS FIELD WAS MISSING
    "vector_sync": "success",
    "user_name": user_name          # e.g., "hermes-ubuntu-private"
}

Qdrant's must filter requires ALL conditions to match. Points without a status field don't match status=activated, so they're excluded from results.

Fix

Set status=activated on all Qdrant points:

# Update all points to have status=activated
requests.post('http://qdrant:6333/collections/neo4j_vec_db/points/payload', json={
    'points': [list_of_all_point_ids],
    'payload': {'status': 'activated'}
})

After fix

Cube	Total Points	With status=activated
hermes-ubuntu-private	93	92 ✓
hermes-worklab-private	64	64 ✓
hermes-shared	2,911	2,911 ✓
hermes-mac-mini-private	30	30 ✓

All cubes now return search results correctly, both via direct API and via the remote gateway.

Recommendation

The MemOS reindex process (or the add endpoint) should ensure the status field is always set to activated when storing memories in Qdrant. This could be:

1. A default value in the Qdrant payload schema
2. A validation step in the add/reindex pipeline
3. A migration script for existing deployments

Side note: _vector_recall_ORIGINAL naming

There is indeed a naming inconsistency in recall.py where _vector_recall_ORIGINAL is defined but _vector_recall is referenced. However, this didn't cause the search failure because the _vector_recall method was properly aliased during our investigation. The primary issue was the missing status field.