René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"memory_heal has no orphan-facet sweep, and facets/remove needs the full targetId+dimension+value triple","articleBody":"## Summary\n\n#1589 was closed by #1591 for the *new deletion* paths, which is the important half — thanks for that. This tracks the two follow-ups that PR body explicitly left out:\n\n> \"The `memory_heal` orphan sweep and `targetId`-only `facets/remove` are separate changes.\" — #1591\n\nBoth matter for existing stores, because a cascade fix cannot clean rows that were already orphaned before it landed.\n\n## 1. `memory_heal` cannot see facets\n\n`src/functions/diagnostics.ts` on `main` has **zero** occurrences of `facet`. The heal categories are actions / leases / sentinels / sketches / signals / sessions / memories / lessons / summaries / semantic / procedural / crystals / insights / mesh — facets are not among them, so there is no supported way to reclaim orphan facet rows.\n\nMeasured on 0.9.30 with 4 orphan rows present:\n\n```\nPOST /agentmemory/diagnostics/heal  {\"dryRun\":true}\n  -> {\"details\":[],\"fixed\":0,\"skipped\":0,\"success\":true}\nPOST /agentmemory/diagnostics/heal\n  -> {\"details\":[],\"fixed\":0,\"skipped\":0,\"success\":true}\n```\n\nBoth runs report success while the orphans survive.\n\n## 2. `facets/remove` requires the full triple, unlike the query side\n\n```\nPOST /agentmemory/facets/query  {\"matchAll\":[\"tool:\u003cname>\"],\"targetType\":\"memory\"}\n  -> 200, returns the facet + targetId\n\nPOST /agentmemory/facets/remove {\"targetId\":\"\u003cid>\"}\n  -> 400 {\"error\":\"targetId and dimension are required\"}\n\nPOST /agentmemory/facets/remove {\"targetId\":\"\u003cid>\",\"dimension\":\"tool\",\"value\":\"\u003cname>\"}\n  -> 200 {\"removed\":1,\"success\":true}\n```\n\nSo the query API identifies a target by id alone, while removal needs you to already know every `(dimension, value)` pair it carries. For a target with N facets that is N calls, each of which has to be discovered from a query first.\n\n## Reproduction of the residue\n\n1. create a memory, tag it with two facets, confirm `facets/query` returns it\n2. delete the memory *before* #1591 landed → `{\"deleted\":1,...}`\n3. later, try to delete it again: `{\"deleted\":0,\"notFound\":[\"\u003cid>\"],\"success\":true}` — the body is gone\n4. `facets/query` for either facet value **still returns that targetId**\n5. `diagnostics/heal` dry-run and real both report `fixed:0`\n6. only per-facet `facets/remove` calls with the full triple clear them\n\n## Why it matters beyond hygiene\n\nA dedupe step that queries facets before writing (`xtool:true`, `tool:\u003cname>`) sees the orphan and concludes the entry already exists, so the real entry is never written. That is exactly how we hit it: an orphan made a compliant re-write look like a duplicate.\n\n## Proposed\n\n1. Add an orphan-facet sweep to `memory_heal`: scan `mem:facets`, drop rows whose `targetId` no longer resolves in the memories (and semantic) store. #1591 already ships the \"resolve first, then delete\" helper (`deleteFacetsForTargets`), so the sweep can reuse it.\n2. Either accept `targetId` alone on `facets/remove` (removing every facet for that target), or document the required triple next to the query API — the current asymmetry is easy to trip over.\n\nAlso worth folding in while it is open: #1591 notes observation, action and `mem:core` targets orphan the same way on their delete paths.\n\nHappy to test a patch against a store that has pre-existing orphans (we can produce them deterministically).","author":{"url":"https://github.com/7889545","@type":"Person","name":"7889545"},"datePublished":"2026-10-25T20:03:55Z","url":"https://github.com/rohitg00/agentmemory/issues/1614"}