Clean targeted fix for the hnswlib update race. The one-hunk approach (delete-before-upsert in process_file) is the right minimal patch — it doesn't reach into HNSW internals, just eliminates the condition that triggers the update path.

The analysis on tool_add_drawer is correct: content-keyed drawer IDs with an existence pre-check make single-item MCP adds structurally safe. Worth adding that explicitly to the PR description as a note for reviewers who might wonder whether tool_add_drawer needs a parallel fix.

One test gap: the test plan marks the regression test as unchecked ([ ] New regression test: mine a file, os.utime() the file, re-mine, assert no crash and new chunks replace old). This is the most important test — without it the fix could regress silently. I'd want to see that test added before merge.

Also: #522 and #523 overlap on the same miner.py change. Both add delete-before-upsert logic, but #522 does it more comprehensively (all three strategies + CLI + MCP). If #522 merges first, #523 becomes a subset. If #523 merges first, #522 will have a conflict in miner.py. Worth flagging the coordination dependency — these should probably be merged in order or deduplicated before review.

MemPalace-AGI dashboard

FYI: #251 already implements this purge-before-re-insert pattern in process_file (from @igorls review item #1 — atomic per-file re-mine). It's part of a broader sync command but the core fix for the hnswlib update-path race is the same: delete existing drawers for the source_file before calling add_drawer() with the fresh chunks.

If #251 lands, this race is fixed as a side effect. If #523 lands first, the narrower scope here is fine and #251 just needs a rebase.

Closing as superseded.

The delete-before-upsert pattern proposed here landed upstream via a different PR — #784 (merged 2026-04-13, shipped v3.3.0) wrapped both miners' delete+insert critical sections in per-file mine_lock, with collection.delete(where={"source_file": ...}) before collection.upsert(...). Same pattern, broader coverage (both miner.py and convo_miner.py), plus cross-process safety via flock.

Additional reinforcements since:

• fix: prevent HNSW index bloat from duplicate add() calls (#525) #544 (v3.3.0): convo_miner add() → upsert() — closes the duplicate-insert path that originally triggered the updatePoint race.
• fix: upgrade chromadb to >=1.5.4 for Python 3.13/3.14 compatibility + fix 1.5.x queue-stall (closes #1006) #1010 (v3.3.2): chromadb pin to >=1.5.4,<2 — the upstream hnswlib binding from the original hnswlib updatePoint race on modified-file re-mine: EXC_BAD_ACCESS in repairConnectionsForUpdate (macOS ARM64, Python 3.13, chromadb 0.6.3) #521 stack is replaced by chromadb_rust_bindings in 1.5.x, so the specific repairConnectionsForUpdate code path no longer exists.

Closing without merge — the fix is in main, just not from this branch.