What's broken

mempalace/backends/chroma.py::_fix_blob_seq_ids (added in #664) runs int.from_bytes(blob, 'big') on every BLOB row in max_seq_id. But chromadb 1.5.x writes its own BLOB format there — b'\x11\x11' followed by six ASCII digits — and the shim reads that as a big-endian u64. The result is a ~1.23×10^18 integer sitting in the column.

chromadb's embeddings_queue filter is seq_id > start, and start is read from max_seq_id.seq_id at segment open. New rows' seq_ids are small (<1e10 even on large palaces), so nothing ever crosses the poisoned threshold. Writes queue and never flush. Old drawers still read fine, which is why the bug is silent until you try to fetch something written after the poisoning.

Repro

Any palace with BLOB-typed max_seq_id.seq_id rows the first time it opens under chromadb 1.5.x with the #664 shim active. Mine got hit on 2026-04-20:

Clean values came from a chroma.sqlite3.pre-sysdb10fix-2026-04-20 backup. 465k+ existing drawers still read; every write after 2026-04-20 silently disappeared.

Fix

Shim: drop max_seq_id from the loop — chromadb owns that format. The embeddings branch stays for real 0.6.x palaces but skips any BLOB starting with b'\x11\x11' as belt-and-braces.

New subcommand mempalace repair --mode max-seq-id restores poisoned rows (detects seq_id > 2^53). Two clean-value sources: --from-sidecar <path> copies exact values out of a pre-corruption chroma.sqlite3 backup, or the default heuristic uses MAX(embeddings.seq_id) over the owning collection. Heuristic matches METADATA max exactly; VECTOR segments land a few seq_ids ahead, which the queue treats as already consumed — skipping a tiny window of already-indexed embeddings.

PR to follow.

Possibly related

• fix: auto-repair BLOB seq_ids from chromadb 0.6→1.5 migration #664 — introduced the shim. This is a regression in its loop.
• bug: fresh pip install mempalace silently broken on chromadb 1.5.x — writes queued but never flush, search returns ghosts #1006 — closed by pinning chromadb, attributed to "segment materialization never runs." Same symptom on 1.5.x; could be this.
• Delete operations silently no-op on palaces migrated from chromadb 0.6.3 → 1.5.8 #1099 — silent no-op deletes after 0.6.3 → 1.5.8. Same migration boundary.
• MCP server stdio transport: add_drawer and kg_add write to WAL but not to ChromaDB/SQLite #538, [CRITICAL] Data Persistence Failure & Faulty Error Handling: mempalace_add_drawer reports success despite result: null in logs #813 — silent write loss reports. Overlap not verified; linking for triage.

Out of scope

• chromadb's choice of max_seq_id BLOB format.
• A status --health command that would have caught this earlier.