Skip to content

[bug] Search API only uses memory_types[0], silently ignoring all other types #78

Description

@wucm667

What broke?

The search API accepts a list of memory_types, but the retrieval logic only uses memory_types[0]. All other types in the list are silently ignored — they are never searched and no results are returned for them.

Additionally, if the first type happens to be one that the search backend doesn't support (e.g., profile, which is stored in MongoDB and only retrievable via the fetch API), the entire search errors out and returns 0 results.

Steps to Reproduce

Case 1 — silent data loss (no error, but incomplete results):

  1. Start EverMemOS
  2. Send: GET /api/v1/memories/search?memory_types=episodic_memory,foresight&query=hello&retrieve_method=hybrid&top_k=5&user_id=test_user&group_id=test_user
  3. Only episodic_memory is searched. foresight is silently ignored — no warning, no error, no results.

Case 2 — error when unsupported type is first:

  1. Send: GET /api/v1/memories/search?memory_types=profile,episodic_memory,foresight&query=hello&retrieve_method=hybrid&top_k=5&user_id=test_user&group_id=test_user
  2. profile (not indexed in ES/Milvus) is taken as memory_types[0] → ERROR. episodic_memory and foresight are never searched. 0 results returned.

What did you expect?

  • The search should iterate over all requested memory_types
  • For each type supported by ES/Milvus (episodic_memory, foresight, event_log), perform keyword + vector search
  • Skip types not supported by the search backend (e.g., profile) with an info log
  • Merge, deduplicate, and rerank the combined results across all types

What happened instead?

All retrieval methods (get_keyword_search_results, get_vector_search_results, _search_hybrid, _search_rrf, retrieve_mem_agentic, _to_response) hardcode memory_types[0]:

# memory_manager.py line 378 (keyword search)
mem_type = memory_types[0]

# memory_manager.py line 501 (vector search)
mem_type = retrieve_mem_request.memory_types[0]

The rest of the list is never read.

When the first type is profile (not in ES_REPO_MAP or Milvus match):

WARNING - memory_manager.py:382 - Unsupported memory_type: MemoryType.PROFILE
ERROR   - memory_manager.py:619 - Error in get_vector_search_results: Unsupported memory type: MemoryType.PROFILE
ERROR   - memory_manager.py:660 - Error in retrieve_mem_hybrid: Unsupported memory type: MemoryType.PROFILE

Note: profile is a fully implemented memory type — it's stored in MongoDB and retrievable via the fetch API (GET /api/v1/memories/fetch). It's only unsupported in the search path (ES/Milvus), which is expected by design.

Environment (quick)

  • OS: Linux (Docker)
  • Python version: 3.12
  • Install method: Docker

Activity

  1. added a commit that references this issue on Feb 24, 2026
    3b889ad
  2. added a commit that references this issue on Mar 2, 2026
    958fa67
  3. added a commit that references this issue on Mar 19, 2026
    4c3a716
  4. cyfyifanchen commented on Jun 6, 2026

    @cyfyifanchen
    Collaborator

    Closing this as part of the EverOS 1.0 issue triage. This issue references the pre-1.0 API or retired infrastructure such as /api/v1/memories, /api/v3/agentic/*, MongoDB, Elasticsearch, Milvus, Redis, Kafka, longjob, or old memory type names. EverOS 1.0 uses POST /api/v1/memory/{add,flush,search,get} with Markdown + SQLite + LanceDB. Migration notes are tracked in PR #258: #258. If the same behavior still occurs on current main with the 1.0 API, please open a fresh issue with a 1.0 repro.

  5. cyfyifanchen commented on Jun 6, 2026

    @cyfyifanchen
    Collaborator

    Post-triage verification: keeping this closed because the 1.0 search contract no longer accepts a memory_types list that can silently ignore later values. Current POST /api/v1/memory/search chooses the owner track via user_id or agent_id and returns typed arrays: episodes, profiles, agent_cases, and agent_skills. Profile inclusion is explicit via include_profile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingmethods

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions