Skip to content

[Bug]: Memory replace with partial old_text on composite entry truncates everything after match #59184

Description

@Rudrymor

Bug Description

What happened
When using the memory tool's replace action with a partial old_text on a composite (multi-section) entry, the replacement truncates everything after the matched text instead of only replacing the matched portion.

The entry is reduced to just the replacement text — all other sections are lost.

Expected behavior
Only the matched old_text portion is replaced with new_text; all other content in the composite entry is preserved.

Environment
Interface: Hermes Desktop (GUI)
Memory provider: built-in

Steps to Reproduce

  1. Have a memory entry with multiple sections:
    Section A
    content A

Section B
content B

Section C
content C

  1. Call memory replace with old_text matching only Section B\ncontent B and new_text containing the updated Section B.

  2. Observe the resulting entry — only the new Section B remains, Sections A and C are gone.

Expected Behavior

Only the matched old_text portion is replaced with new_text. All other content in the composite entry is preserved.

Actual Behavior

Everything before and after the matched old_text is truncated. The entry is reduced to just the replacement text. For example, a 10-section entry (Hermes, Windows, Search, Wiki, etc.) after partial replace contained only the updated Search section — the other 9 sections were lost.

Affected Component

Agent Core (conversation loop, context compression, memory)

Messaging Platform (if gateway-related)

No response

Debug Report

Debug report not generated — skipped due to PII concerns.

Operating System

Windows 10

Python Version

3.11.15

Hermes Version

0.18.0

Additional Logs / Traceback (optional)

Memory entry had 10 sections (~2000 chars total)
Called memory replace with old_text matching only the "## Search" section (~200 chars) and new_text with expanded Search content
Result: memory contained ONLY the new Search section — all other 9 sections were lost
Confirmed by calling memory replace with old_text of full expected entry — got "No entry match" error, confirming the composite was destroyed

Root Cause Analysis (optional)

The memory tool's replace handler appears to treat old_text as a prefix/suffix boundary rather than an exact substring match. When old_text matches in the middle of a composite entry, the replacement operation drops everything outside the match window instead of preserving it.

Likely in tools/memory_tool.py or similar — the replace logic splits on old_text but discards the prefix and suffix instead of concatenating them with new_text.

Proposed Fix (optional)

Proposed Fix: Ensure the replace operation preserves content before and after the matched substring:
result = prefix + new_text + suffix
Instead of: result = new_text

Are you willing to submit a PR for this?

  • I'd like to fix this myself and submit a PR

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Medium — degraded but workaround existsarea/memoryMemory subsystem: store, providers, sync, background reviewsbugcomp/agentCore agent runtime: loop, agent_init, prompt builder, context-compression, responses endpointcomp/desktopElectron desktop app (apps/desktop/*)needs-reproBug needs reproduction stepstool/memoryMemory tool and memory providerstype/bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions