[BUG] `DELETE /knowledge/entities/{id}` returns 500 for non-markdown (file-type) entities

[ryanstraight]

Bug Description

The per-entity delete endpoint returns 500 Internal Server Error for entities whose note_type is file (non-.md: .qmd, .csv, .py, .txt, .yml, sync-conflict files, etc.). Markdown note-entities delete cleanly. POST .../knowledge/delete-directory deletes the same file-type entities without error, so the data model supports their deletion — only the per-entity endpoint fails.

Steps To Reproduce

1. Install version 0.20.3 (pip install basic-memory) and authenticate a cloud tenant.
2. Identify a file-type entity (e.g. a .qmd or .csv) and confirm it exists: GET /v2/projects/<project_id>/knowledge/entities/<entity_id> → 200.
3. Delete it: DELETE /v2/projects/<project_id>/knowledge/entities/<entity_id> → 500 Internal Server Error (repeatable, not transient — same entity 500s on retry).
4. Delete its parent directory instead: POST /v2/projects/<project_id>/knowledge/delete-directory with {"directory": "<parent/dir>"} → 200, deletes it and its siblings successfully.

Expected Behavior

DELETE .../entities/{id} should delete file-type entities the same way delete-directory does — or at minimum return a meaningful error rather than a 500.

Actual Behavior

500 Internal Server Error for every non-.md entity. Observed at scale: in a bulk removal of ~910 entities via the per-entity endpoint, all 571 .md succeeded and all 339 non-.md returned 500. A subsequent delete-directory pass cleared 100% of the 339 with zero failures.

Environment

• OS: Windows 11 (10.0.26220)
• Python version: 3.13.2
• Basic Memory version: 0.20.3
• Installation method: pip (--user)
• Claude Desktop version (if applicable): N/A (reproduced via cloud REST API)

Additional Context

• The 500 body carries no detail (Internal Server Error).
• Related (checked — distinct): Add delete-note CLI command (bm tool delete-note) #879 (add delete-note CLI) documents these same DELETE .../entities/{id} and delete-directory endpoints as fully working; it does not cover this file-type 500. No existing issue found for the 500-on-non-markdown behavior.

Possible Solution

The per-entity delete path likely assumes markdown structure during post-delete cleanup (search-index removal / relation / embedding cascade) and throws on file-type (note_type: file) entities, whereas entity_service.delete_directory() uses a path that handles them. Aligning the single-entity delete with the directory-delete code path is the likely fix.

[phernandez]

Thanks for the detailed report — the 571 markdown / 339 non-markdown split and the working delete-directory comparison made this easy to pin down. The per-entity delete was doing markdown-specific cleanup (search-index removal keyed off permalinks/observations/relations that file-type entities don't have), while delete-directory used a tolerant per-file path — which matches exactly what you saw.

On main, single-entity delete now runs through the shared accepted-note delete path (#1002, #1054): search and vector rows are deleted by entity id rather than permalink, and non-markdown files skip markdown-specific processing. Those commits aren't in a released build yet, and there's no regression test for the non-markdown single-delete case — we'll add one and make sure this lands in the next release before closing this out.

[phernandez]

Confirmed fixed on main.

• refactor(core): add shared runtime orchestration #1002 and refactor(core): structure campaign — collapse seams, honest types, typed boundaries #1054 route single-entity deletion through the shared accepted-note cleanup path, including non-Markdown file entities.
• test(api): cover single-entity delete for non-markdown file entities #1056 adds the exact regression test for deleting a non-Markdown entity and verifies removal of the entity, search row, and file.

The regression passes on current main. Closing as completed.