hermes - ✅(Solved) Fix Broken memory user_id regression test imports nonexistent agent.builtin_memory_provider module [1 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#14402Fetched 2026-04-24 06:17:30
View on GitHub
Comments
2
Participants
3
Timeline
8
Reactions
0
Timeline (top)
labeled ×5commented ×2cross-referenced ×1

tests/agent/test_memory_user_id.py::TestMemoryManagerUserIdThreading::test_multiple_providers_all_receive_user_id currently imports agent.builtin_memory_provider.BuiltinMemoryProvider, but that module/class does not exist in the repository.

The failure blocks the intended regression coverage for mixed built-in + external memory-provider initialization and also highlights code/docs drift around MemoryManager's "always-on built-in provider" story.

Error Message

E ModuleNotFoundError: No module named 'agent.builtin_memory_provider'

Root Cause

tests/agent/test_memory_user_id.py::TestMemoryManagerUserIdThreading::test_multiple_providers_all_receive_user_id currently imports agent.builtin_memory_provider.BuiltinMemoryProvider, but that module/class does not exist in the repository.

The failure blocks the intended regression coverage for mixed built-in + external memory-provider initialization and also highlights code/docs drift around MemoryManager's "always-on built-in provider" story.

Fix Action

Fixed

PR fix notes

PR #14446: docs(agent): remove stale BuiltinMemoryProvider references from memory module docstrings

Description (problem / solution / changelog)

Problem

Fixes #14402.

agent/memory_manager.py and agent/memory_provider.py contain stale docstring references to BuiltinMemoryProvider — a class that no longer exists in the repository. This causes confusion for contributors who:

  1. Read the example usage in memory_manager.py and try add_provider(BuiltinMemoryProvider(...))ImportError
  2. See memory_provider.py claiming BuiltinMemoryProvider — always present, not removable and look for it in the codebase → not found

Verification: The regression test test_memory_user_id.py::TestMemoryManagerUserIdThreading already passes without any BuiltinMemoryProvider reference — it uses RecordingProvider instances directly. All 5 tests in that class pass on current main.

Fix

Update both docstrings to reflect the actual current architecture:

  • MemoryManager accepts external plugin providers only (one at a time)
  • No mention of BuiltinMemoryProvider since it doesn't exist
  • Example code in memory_manager.py updated to remove the phantom add_provider(BuiltinMemoryProvider(...)) call

Testing

python3 -m pytest tests/agent/test_memory_user_id.py::TestMemoryManagerUserIdThreading -v
# 5 passed

Changed files

  • agent/memory_manager.py (modified, +3/-6)
  • agent/memory_provider.py (modified, +8/-9)

Code Example

source venv/bin/activate
pytest -q tests/agent/test_memory_user_id.py::TestMemoryManagerUserIdThreading::test_multiple_providers_all_receive_user_id -vv

---

E   ModuleNotFoundError: No module named 'agent.builtin_memory_provider'
RAW_BUFFERClick to expand / collapse

Summary

tests/agent/test_memory_user_id.py::TestMemoryManagerUserIdThreading::test_multiple_providers_all_receive_user_id currently imports agent.builtin_memory_provider.BuiltinMemoryProvider, but that module/class does not exist in the repository.

The failure blocks the intended regression coverage for mixed built-in + external memory-provider initialization and also highlights code/docs drift around MemoryManager's "always-on built-in provider" story.

Affected files / lines

  • tests/agent/test_memory_user_id.py:112-128
  • agent/memory_manager.py:1-18, 71-129
  • agent/memory_provider.py:3-14
  • run_agent.py:1191-1218

Why this is a bug

The test suite claims to verify that both the built-in memory layer and an external provider receive threaded user_id, but the regression test cannot even import the built-in provider abstraction it expects.

This is more than a flaky test name mismatch:

  • agent/memory_manager.py and agent/memory_provider.py still document an always-present BuiltinMemoryProvider
  • run_agent.py now only instantiates MemoryManager when memory.provider is configured, and only adds the external plugin
  • there is no agent/builtin_memory_provider.py implementation to exercise the documented path

So the code, docs, and tests are out of sync, and the regression coverage for this memory path is currently dead.

Minimal reproduction / evidence

Run:

source venv/bin/activate
pytest -q tests/agent/test_memory_user_id.py::TestMemoryManagerUserIdThreading::test_multiple_providers_all_receive_user_id -vv

Current failure:

E   ModuleNotFoundError: No module named 'agent.builtin_memory_provider'

Expected behavior

Either:

  1. the built-in memory provider abstraction exists and the regression test can exercise it, or
  2. the test/docs are updated to match the current architecture and coverage is restored through the real built-in memory path.

Actual behavior

The regression test imports a module that does not exist, so the intended user_id-threading coverage never runs.

Suggested investigation direction

  • Decide whether BuiltinMemoryProvider is still a real architectural concept.
  • If yes, restore the implementation/module and wire it through MemoryManager.
  • If no, delete the stale abstraction from docs/comments/tests and replace this test with coverage against the actual built-in memory path that ships today.

extent analysis

TL;DR

The most likely fix is to either restore the missing BuiltinMemoryProvider implementation or update the test and documentation to match the current architecture.

Guidance

  • Investigate whether BuiltinMemoryProvider is still a valid architectural concept and decide on its fate.
  • If BuiltinMemoryProvider is still needed, create the missing agent/builtin_memory_provider.py module and implement the BuiltinMemoryProvider class.
  • If BuiltinMemoryProvider is no longer needed, update the test test_memory_user_id.py to remove references to it and instead test the actual built-in memory path.
  • Review and update the documentation in agent/memory_manager.py and agent/memory_provider.py to reflect the chosen approach.

Example

No code example is provided as the issue does not contain enough information to suggest a specific implementation.

Notes

The solution depends on the outcome of the investigation into the validity of BuiltinMemoryProvider. The chosen approach should ensure that the test coverage is restored and the code, documentation, and tests are in sync.

Recommendation

Apply workaround: Update the test and documentation to match the current architecture, as it seems that BuiltinMemoryProvider is no longer a part of the codebase. This approach is chosen because the issue suggests that the current architecture does not include BuiltinMemoryProvider, and updating the test and documentation will restore the regression coverage.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Either:

  1. the built-in memory provider abstraction exists and the regression test can exercise it, or
  2. the test/docs are updated to match the current architecture and coverage is restored through the real built-in memory path.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix Broken memory user_id regression test imports nonexistent agent.builtin_memory_provider module [1 pull requests, 2 comments, 3 participants]