Repository navigation
Please publish 587cd620 (6h doc bucketing) — 2.1.15 mints one document per session and duplicates standing facts #60
Description
Installed: @supermemory/openclaw-supermemory@2.1.15 (npm latest, published 2026-06-10) against a self-hosted supermemory backend.
Problem
buildDocumentId in memory.ts keys the customId on the session (session_<sessionKey>), so every OpenClaw session becomes a new document. The extractor then re-derives the same standing facts from scratch in each one.
Result on my instance: 757 documents in a single container, and one standing fact ("Scout reads the channels: …") stored nine times. Two of those nine are semantically wrong — they name a different channel set — so the duplicates aren't just noise, they actively outrank the correct version in recall and crowd useful memories out of the injection block.
It's already fixed, just not released
587cd620 — "bucket capture docs by 6h utc window (#59)", 2026-06-21 — swaps the per-session customId for a 6h UTC bucket so turns in the same window share one document. That commit landed 11 days after 2.1.15 shipped, and there has been no release since, so there is no upgrade path to it. Self-hosters on current latest all have the duplicating version.
Would you consider cutting a release that includes it? Happy to test a prerelease.
Related
Possibly the same root cause behind #24 (stored memories not reliably searchable/deletable) — a fact spread across N documents is harder to match and harder to fully remove.
Workaround for anyone else hitting this
Backporting the bucketing change onto the installed dist/ fixes new writes; existing duplicates need a separate /v4/memories/forget-matching sweep.
Activity
Dhravya commentedon Aug 3, 2026
Hey, thanks for reporting this, it has been fixed now
brenthorn commentedon Aug 4, 2026
Confirmed on 2.1.16 — thanks for the quick turnaround.
Verified the published dist rather than just the tag:
No
sessionKeyin the id, so concurrent sessions in the same 6h window now share a document instead of minting one each. Upgraded, restarted, and new captures are bucketing correctly.One note for anyone landing here from search: the release stops new duplicates but does nothing about the backlog. On our install 2.1.15 had produced ~1.9k redundant memory entries out of 6.3k, including standing facts stored 20+ times where stale variants outranked the current one in recall. We cleared ours with a dedup pass over
POST /v4/memories/list+DELETE /v4/memories(soft forget, so it's reversible). Might be worth a note in the release/README that existing installs need a one-off sweep.Closing — fix is published and working.