# 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.