fix: migration drops mem_branches on every startup + UTF-8 panic in diff preview

[aptend]

Problem

Two bugs that affect both MCP embedded mode and API mode:

1. mem_branches dropped on every startup

query_has_rows() in store.rs executes SQL like SELECT COUNT(*) > 0 FROM .... MatrixOne returns a bool for COUNT(*) > 0, but sqlx's query_scalar::<_, i64> cannot decode bool → unwrap_or(0) → always returns false.

This causes migrate_user() to take the DROP TABLE IF EXISTS mem_branches + CREATE TABLE path on every startup, wiping all branch registrations. The branch tables themselves survive (they're MatrixOne CoW tables), but the metadata linking names to tables is lost.

Fix: Strip the > 0 suffix from the SQL and compare in Rust instead.

2. UTF-8 panic in memory_diff preview

git_tools.rs truncates diff content preview with &r.content[..80]. For multi-byte UTF-8 content (e.g. CJK characters), byte index 80 can land inside a character, causing a panic that crashes the MCP/API process.

Fix: Use floor_char_boundary(80) to find the nearest valid character boundary.

Changes

• memoria-storage/src/store.rs: query_has_rows() strips "> 0" suffix before executing
• memoria-mcp/src/git_tools.rs: diff preview uses floor_char_boundary()

[Copilot]

Pull request overview

Fixes two MatrixOne/MCP stability issues: preventing accidental mem_branches metadata resets during startup migrations and avoiding UTF-8 slicing panics when generating memory_diff previews.

Changes:

• Adjust query_has_rows() to normalize COUNT(*) > 0-style probes for MatrixOne/sqlx decoding compatibility.
• Truncate memory_diff preview strings using floor_char_boundary() to avoid invalid UTF-8 slicing.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
memoria/crates/memoria-storage/src/store.rs	Updates query_has_rows() SQL normalization used by migration probes that gate schema changes.
memoria/crates/memoria-mcp/src/git_tools.rs	Fixes diff preview truncation to avoid panics on multibyte UTF-8 content.

Comments suppressed due to low confidence (1)

memoria/crates/memoria-storage/src/store.rs:52

• query_has_rows() currently swallows all SQLx errors via .await.unwrap_or(0), treating failures as “no rows”. In migrate_user() this boolean is used to decide destructive paths (e.g., dropping/recreating mem_branches), so transient DB errors or decode errors can silently trigger data-lossy migrations. Consider returning Result<bool, MemoriaError> (or at least logging and failing startup) for probe failures that gate DROP/CREATE behavior.

    sqlx::query_scalar::<_, i64>(&sql)
        .fetch_one(pool)
        .await
        .unwrap_or(0)
        > 0

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The SQL rewrite in query_has_rows() only strips a literal "> 0" at the end of the whole SQL string. That won’t affect queries of the form SELECT COUNT(*) > 0 FROM ... (where > 0 is inside the SELECT expression), which is the failure mode described in the PR. Also, when no suffix matches, the code falls back to sql.to_string() (the original untrimmed input), so the earlier trim_end_matches(';') is effectively ignored. Recommend normalizing the query using the trimmed value and rewriting the COUNT(*) > 0 expression (or updating callers to pass plain COUNT(*)).

[Copilot]

Please add a regression test for the diff preview truncation with multi-byte UTF-8 (e.g., CJK) to ensure memory_diff never panics when slicing previews. This file already has unit tests, so it should be straightforward to cover the new floor_char_boundary() logic.