Skip to content

fix(agentic): search API queries all requested memory_types, not just the first#238

Open
Fearvox wants to merge 1 commit into
EverMind-AI:mainfrom
Fearvox:fix/issue-78-multi-type-search
Open

fix(agentic): search API queries all requested memory_types, not just the first#238
Fearvox wants to merge 1 commit into
EverMind-AI:mainfrom
Fearvox:fix/issue-78-multi-type-search

Conversation

@Fearvox
Copy link
Copy Markdown
Collaborator

@Fearvox Fearvox commented Jun 3, 2026

What

The search API only ever queried memory_types[0]. A request asking for several memory types (for example [EPISODIC_MEMORY, AGENT_CASE]) silently returned hits from the first type and dropped every other type — no error, no warning, just missing results. This is the exact defect reported in #78.

This PR makes retrieve_mem query every requested memory type:

  • Keyword search (get_keyword_search_results) now iterates all requested types over ES_REPO_MAP instead of indexing memory_types[0], marks each hit with its memory_type, merges, and sorts by score.
  • Vector search (get_vector_search_results) does the same over a new MILVUS_REPO_MAP, replacing the single match mem_type block that handled only one type.
  • Hybrid dedup previously keyed on id alone, so two distinct collections that happen to share a backend id erased each other. Dedup now keys on (memory_type, id) via the new _hit_identity helper, and results are score-sorted via _sort_hits_by_score.

Small shared helpers (_memory_type_label, _hit_score, _sort_hits_by_score, _hit_identity) replace the repeated memory_types[0].value if ... else 'unknown' idiom that caused the bug in the first place.

Why

memory_types[0] is a silent data-loss bug: multi-type retrieval is a documented capability, and callers requesting two or more types had no way to know the extra types were being ignored. See #78.

Tests

Adds methods/EverCore/tests/test_memory_manager_multi_type_search.py, which runs fully offline (repositories monkeypatched, no ES/Milvus/live stack required):

  • test_keyword_search_queries_all_requested_memory_types — asserts both EPISODIC_MEMORY and AGENT_CASE return hits, score-sorted.
  • test_hybrid_dedupe_keeps_same_id_from_distinct_memory_types — asserts hybrid dedup keeps same-id hits from distinct memory types instead of collapsing them.

Run locally:

cd methods/EverCore
uv sync
PYTHONPATH=src pytest tests/test_memory_manager_multi_type_search.py -v
# (this is the `make test` path; PYTHONPATH=src is required or imports fail)

Result: 2 passed.

Scope

Surgical: two files only — methods/EverCore/src/agentic_layer/memory_manager.py and its new regression test. No README, no demo, no unrelated changes.

Closes #78.

Credit

This fix builds on prior community work that diagnosed and proposed the same change. Co-authors preserved on the commit:

Co-authored-by: Exploreunive 117084012+Exploreunive@users.noreply.github.com
Co-authored-by: Jah-yee 166608075+Jah-yee@users.noreply.github.com
Co-authored-by: wucm667 109257021+wucm667@users.noreply.github.com
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code

… the first

The keyword and vector search paths read only `memory_types[0]`, so any
request asking for multiple memory types silently returned hits from the
first type and dropped the rest. retrieve_mem now iterates every requested
memory type for both keyword (ES_REPO_MAP) and vector (MILVUS_REPO_MAP)
search, merges the results, and sorts by score.

Hybrid dedup is also fixed: previously hits were deduped by `id` alone, so
two distinct collections that happen to share a backend id erased each
other. Dedup now keys on `(memory_type, id)` via `_hit_identity`.

Adds an offline regression test (monkeypatched repos, no live stack) that
asserts both EPISODIC_MEMORY and AGENT_CASE return hits and that hybrid
dedup keeps same-id hits from distinct memory types.

Closes #78

Co-authored-by: Exploreunive <117084012+Exploreunive@users.noreply.github.com>
Co-authored-by: Jah-yee <166608075+Jah-yee@users.noreply.github.com>
Co-authored-by: wucm667 <109257021+wucm667@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings June 3, 2026 02:40
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

2 participants