Bug: Split-parent memories have two consistency issues

[micnis]

Summary

Two independent bugs affect memories that Recallium internally splits into chunks:

1. modify_memory update does not reach expand_memories

   • modify_memory(action="update") returns success.
   • search_memories(search_mode="keyword") can find phrases from the updated content.
   • But expand_memories still returns the old assembled content.

2. store_memory can introduce duplicated sections in assembled output

   • On larger memories, expand_memories returns content with contiguous duplicated markdown sections near chunk boundaries.
   • The content is not missing, but the assembled output is corrupted.

Severity

High. This is a silent consistency problem in a core read/write path for chunked memories.

---

Environment

• Recallium version: v0.8.373
• Integration: MCP server
• Client context: Claude via Anthropic tool-use API

Observed on split-parent memories ranging from about 6 KB to 20 KB. Duplication was reproduced on 4 fresh memories; update divergence was reproduced 3 times across 2 memories.

---

Bug 1: modify_memory updates index, but not assembled reads

Minimal reproduction

1. Call store_memory(...) with content large enough to become a split-parent memory.

2. Call expand_memories(memory_ids=[id]) and save the returned content as baseline.

3. Call:

   modify_memory(
       action="update",
       memory_id=id,
       content="<clearly different content with a unique sentinel phrase>"
   )

4. Call expand_memories(memory_ids=[id]) again.

5. Call:

   search_memories(
       query="<sentinel phrase>",
       search_mode="keyword",
       project_name="test"
   )

Expected

After a successful modify_memory, both:

• expand_memories
• search_memories

should reflect the new content.

Actual

• modify_memory reports success.
• search_memories finds the new content.
• expand_memories still returns the pre-update assembled content.

Why this matters

The write path and read path appear to diverge for split-parent memories. An agent can successfully write new content, then immediately read back stale data.

Diagnostics already ruled out

• Not eventual consistency: repeated reads minutes later still return stale content.
• Not payload truncation: modify_memory echoes the new content in its response.
• Not a total persistence failure: keyword search sees the new content.
• Not limited to parent expansion: expanding child chunk IDs also returns the same stale assembled content.

---

Bug 2: store_memory can duplicate sections at chunk boundaries

Minimal reproduction

1. Call store_memory(...) with ~10 KB or more of structured markdown containing multiple ## sections.
2. Call expand_memories(memory_ids=[id]).

Expected

The assembled content should match the input content exactly.

Actual

One or more sections near chunk boundaries are duplicated contiguously in the assembled output, for example:

## Section X
## Section X
...

Notes

• Reproduced on 4 independently created memories.
• Present on the first read after store_memory.
• Observed even before any modify_memory call.
• This looks like an overlap / off-by-one issue in chunk assembly.

---

Expected vs actual

Area	Expected	Actual
modify_memory on split-parent	Update is reflected by expand_memories and search_memories	Only search_memories reflects update
expand_memories after update	Returns new content	Returns old content
store_memory on larger split-parent	Assembled output matches input exactly	Sections can be duplicated at chunk boundaries
Error handling	Clear error or partial-write signal on failure	No warning or error

[recallium-ai]

The issue has been traced back to the fact that we need to update the environment file. The changes were made recently to enable switching Embedding Models from hugging face (to tackle different languages). The fix is being worked on. v395 should be out shortly and fix this issue. Recommend that you update your .env file once the new version is out. Will update this ticket back here shortly.

PS: Join our reddit for updates: https://www.reddit.com/r/recallium/

[recallium-ai]

Just released: 0.8.420: that solves this split issue. Please give it a try and let us know.

[micnis]

Yes, v0.8.420 solves both bugs reported in this issue, thank you.

However, while verifying the bugs were gone, I found another problem which deserves an own issue ticket probably:

When a split-parent memory is updated and recreated (old ID inactivated, new ID created), external memories that held a related_memory_ids link to the old ID are partially migrated but not cleaned up:

• ✅ The new memory ID is automatically added to the referencing memory's related list
• ❌ The old (now inactive) ID is not removed, leaving a dead link marked as "not found or inactive"

Consequence: Each update to a split-parent memory accumulates one additional stale link in every memory that references it. Over time this degrades the quality of the relationship graph.

Reproduction:

1. Store a large memory (>10 KB) → gets split into chunks, e.g. ID A
2. Store a small memory with related_memory_ids: [A]
3. Update memory A → recreated as B, A inactivated
4. Expand the small memory → related list now shows both A (not found or inactive) and B

Tested on: v0.8.420 via MCP

[recallium-ai]

Thanks @micnis for really sticking with this feature! The latest version 0.8.447 should resolve this now.