Skip to content

fix(mcp): mark sqlite_integrity not-applicable on non-chroma backends (#1931) - #1946

Merged
igorls merged 1 commit into
MemPalace:developfrom
mvalentsev:fix/status-integrity-non-chroma
Jul 8, 2026
Merged

fix(mcp): mark sqlite_integrity not-applicable on non-chroma backends (#1931)#1946
igorls merged 1 commit into
MemPalace:developfrom
mvalentsev:fix/status-integrity-non-chroma

Conversation

@mvalentsev

Copy link
Copy Markdown
Contributor

Fixes #1931

What does this PR do?

On a non-chroma backend (qdrant, pgvector, sqlite_exact, sqlite_vec) the MCP
mempalace_status tool reported a passing SQLite integrity check that never ran:

"sqlite_integrity": { "checked": true, "ok": true,
                      "sqlite_path": ".../chroma.sqlite3",
                      "error_count": 0, "errors": [] }

_refresh_sqlite_integrity_status() already short-circuits the check for
non-chroma backends, and chroma.sqlite3 does not exist for the active backend,
so this reads as "integrity verified OK" when nothing was verified and points at
a file that is not there.

_sqlite_integrity_payload() now detects a non-chroma backend and reports the
check as not-applicable:

"sqlite_integrity": { "checked": false, "ok": null, "sqlite_path": "",
                      "error_count": 0, "errors": [],
                      "reason": "chroma.sqlite3 integrity check does not run for backend 'qdrant'" }

Recorded errors only ever come from the chroma path, so a genuine corruption
report is still surfaced unchanged; only the clean non-chroma case is
reclassified. The chroma payload keeps the same keys, so existing clients are
unaffected, and backend resolution is wrapped so status output cannot raise.

Scope is limited to the status payload. repair.sqlite_integrity_errors() is
reached only behind existing chroma guards, so it is left unchanged.

How to test

uv run pytest tests/test_mcp_server.py -k sqlite_integrity

New tests cover the non-chroma not-applicable payload, an unresolved-backend
fallback, and a regression guard that the chroma payload is unchanged.

Manual check on any non-chroma palace (for example MEMPALACE_BACKEND=sqlite_exact):
mempalace_status now returns sqlite_integrity.checked == false and
ok == null with a reason, instead of true/true referencing a
non-existent chroma.sqlite3.

Checklist

  • Tests pass (python -m pytest tests/ -v)
  • No hardcoded paths
  • Linter passes (ruff check .)

…MemPalace#1931)

mempalace_status reported a passing SQLite integrity check on non-chroma
backends (checked/ok true, sqlite_path pointing at a chroma.sqlite3 that does
not exist) even though _refresh_sqlite_integrity_status short-circuits the
check there. _sqlite_integrity_payload now reports the check as not-applicable
(checked false, ok null, reason) for non-chroma backends, keeping the chroma
payload shape and error surfacing unchanged.

Co-Authored-By: Zoz92 <66385795+Zoz92@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

status/sqlite_integrity hardcodes chroma.sqlite3, always reports ok:true on non-chroma backends

2 participants