DEV Community

Mohammed Rafay
Mohammed Rafay

Posted on Originally published at memorysync.hashnode.dev

LlamaIndex Memory drops your priority=1 memory block first

Disclosure: I work on MemorySync (I'm Mohammed, the founder). I drafted this page with AI assistance and checked it against the source issue, the linked PR and the MemorySync LlamaIndex guide on Oct 28, 2026. I didn't run any code for this page.

The question

run-llama/llama_index#23090 reports that when memory blocks plus short-term chat history exceed token_limit, Memory._truncate_memory_blocks drops blocks in ascending priority order. So the block with priority=1 (documented as highest priority) is truncated first, and priority=2 survives. With the docs' own example (FactExtractionMemoryBlock at 1, VectorMemoryBlock at 2), condensed facts go before bulk retrieval.

Status (checked 2026-10-28): open, 3 comments. A commenter pointed to PR #23093 ("fix(core): truncate lowest-priority memory blocks first"), but that PR is now closed without being merged, so no fix has landed as far as the issue shows.

Workarounds

Not run for this page; the issue includes a short repro you can run against your installed version first.

  • Use priority=0 for the block you can't lose. Per the field's docs, 0 means never truncate; the issue doesn't report that being broken.
  • Raise token_limit or shrink blocks so truncation doesn't trigger in normal conversations.
  • Don't rely on the 1-vs-2 order until a fix ships. If you must, test which block survives on your version with the issue's repro and set priorities to match the observed behaviour, then re-check after upgrades.

Common questions

Is there a fix?
Not as of Oct 28, 2026: the issue is open, and PR #23093 was closed without being merged.

Which priority is safe?
priority=0, documented as never truncated. The issue doesn't report that being broken.

Where MemorySync fits

Only if you use it already or are evaluating it. The MemorySync LlamaIndex guide documents a MemorySyncMemoryBlock whose atruncate drops its lowest-ranked lines instead of the whole block. That changes what happens to that one block when it's truncated; it doesn't fix the order bug in Memory itself. To see save and recall in your browser first, try the MemorySync playground.

Sources

  • run-llama/llama_index#23090, "[Bug]: Memory truncates highest-priority memory blocks first" (read 2026-10-28)
  • run-llama/llama_index PR #23093 (closed, not merged; read 2026-10-28)
  • MemorySync LlamaIndex guide: docs.memorysync.io/guides/llamaindex

Top comments (0)