mirror of
https://github.com/basicmachines-co/basic-memory
synced 2026-06-21 13:47:35 +00:00
4fd9cae293
`write_note(overwrite=True)` caught the 409 from create_entity and then called `knowledge_client.resolve_entity(entity.permalink)` with the default `strict=False`. In workspace-prefixed palaces the client-built permalink omits the workspace slug, so exact permalink lookup misses and the fuzzy fallback could pick an orphan row that shares tokens with the canonical permalink. The update then wrote to the orphan, leaving the canonical row stale. On the next overwrite the permalink uniqueness check in `_resolve_schema_permalink` found duplicate rows and minted `-1`/`-2` suffixes on the canonical entity, accumulating orphans on every re-synthesis run. The 409 came from a `file_service.exists(file_path)` check in `prepare_create_entity_content`, so the file_path is the authoritative key for the canonical row — no fuzzy matching needed. Resolve by file_path with `strict=True`, POSIX-normalized so Windows clients send the form the server stores. Adds a regression test that spies on `resolve_entity` and asserts the identifier and `strict` flag, plus checks that no `-1`/`-2` suffix is minted under the canonical permalink. Reported in basic-memory-bug-report Issue 1. Signed-off-by: Dennis Hempel <uhg.dennnis@gmail.com>