mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-11-04 10:48:20 +00:00
Martin Vogel
2acbd3b028
Three small items promised in the #2315 review; behaviour is otherwise unchanged. 1. A failed ADR restore on artifact import is no longer silent (src/pipeline/artifact.c). The import dropped both a failed reopen of the installed DB and the status of cbm_store_adr_restore_from_graph_if_absent, so a team ADR that never reached the sidecar left no trace. The restore moves into artifact_import_restore_adr, which logs level=warn msg=artifact.import err=adr_restore detail=<store error> path=<db> on either failure. The import still returns 0: the graph DB is already installed when the restore runs, and the restore stays best-effort as documented. adr_restore_if_absent now sets the store error for its begin, copy and commit failures, so the logged detail names the failing step. 2. The doc comment of adr_copy_legacy_once sat above adr_copy_rows, stacked on top of the comment that documents adr_copy_rows, which left adr_copy_legacy_once undocumented. It now sits above adr_copy_legacy_once (src/store/store.c). 3. adr_restore_if_absent no longer inserts the migrated marker. That INSERT OR IGNORE could never change state. Its only caller, cbm_store_adr_restore_from_graph_if_absent, takes the sidecar handle from adr_conn_write, which hands out a handle (cached or fresh) only after adr_copy_legacy_once returned OK, and that function returns OK only when the marker row is already committed (fast path, or the re-check under the write lock) or it just inserted and committed it. No code deletes an adr_meta row, so the insert hit the existing primary key every time, and its result was discarded anyway. Tests: artifact_import_logs_failed_adr_restore puts a directory at <db>.adr.db (the hook-free trick from the #2315 pipeline test), then asserts the import still succeeds, the graph DB is installed, and the warn line carries the store reason. It is red without the artifact.c change. artifact_export_roundtrip_keeps_adr now also asserts that the fresh destination sidecar is marked migrated after the import, which pins the invariant item 3 relies on. Refs #2315 Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>