omnigraph/docs/releases/v0.7.1.md

Omnigraph v0.7.1

A patch release on top of v0.7.0: three correctness fixes (camelCase filters, cluster-apply crash loops, branch-merge OOM on embedding tables), one CLI catalog-metadata improvement, and a warm-read performance fix. No breaking changes, no on-disk format change, and no migration — drop-in over v0.7.0.

Fixes

• camelCase property filters now execute (#283). A query — or a chained mutation — that filtered on a camelCase schema field (e.g. repoName) linted and planned cleanly but failed at run time with No field named reponame. Column names are case sensitive. The identifier's case was destroyed at two engine→Lance boundaries: the read-filter pushdown built the column with a case-normalizing constructor, and the pending-batch mutation scan re-parsed the predicate through a normalizing SQL context. Both now preserve case (the read path uses a case-preserving column reference; the pending scan disables SQL identifier normalization), so camelCase fields work consistently in read and write predicates and a camelCase @index equality still routes to the scalar index. The fix is correct-by-construction rather than a per-query guard; a regression test pins index routing so a silent full-scan fallback can't slip back in.

• cluster apply no longer crash-loops a booting server (#284). Applying a schema change while a graph had non-main (agent/review) branches, or a migration that needed a backfill, could throw a freshly-booting omnigraph-server --cluster into an unescapable crash loop. Neither input is an engine bug — the engine rejects both cleanly and before moving any graph state — but cluster apply wrote a recovery sidecar before calling the engine and left it in place on the clean rejection, and the server refuses to boot while a sidecar is pending. The asymmetric-cleanup path is fixed so a pre-movement rejection leaves no stale sidecar, breaking the loop.

• Branch-merge fast-forward no longer OOMs on embedding tables (#277). A branch→main fast-forward merge of a forked, embedding-bearing table re-derived the whole branch through a single Lance merge_insert — a full-outer hash join over the entire delta — which exhausted the DataFusion memory pool on high-dimensional embeddings (e.g. 8k rows × 3072-dim) and hung or failed the merge. New rows now stream through stage_append (no hash join), only genuinely-changed rows are upserted, embeddings are no longer stringified to diff them, and index coverage defers to the reconciler, so a fast-forward merge completes in bounded work. The three-way merge path is unchanged.

Improvements

• omnigraph queries list surfaces stored-query @description / @instruction (#280). The CLI now shows a stored query's catalog metadata — what it does and how to invoke it — in both human and --json output, matching what GET /queries already returned. Previously both fields were silently dropped on the CLI side.

• Warm reads no longer pay an O(history) metadata tax (#268). Warm reads used to re-derive per-query metadata (coordinator re-open, __manifest + commit-graph re-scans, per-table re-open, double schema validation) on a cost that scaled with commit history and never warmed up. A warm same-branch read now does one cheap version probe, one schema read, and zero table opens on a warm repeat (warm coordinator reuse, open-by-location+version, validate-once, held Dataset handles + one shared Lance Session per graph). This also closes a commit-DAG fork where a same-branch write after an external commit could append off a stale cached head.

Upgrade notes

Drop-in over v0.7.0 — no configuration, schema, or data changes. Upgrade the server and CLI together as usual. Graphs created on v0.7.0 read and write identically on v0.7.1.