ORM: every patch on an aggregateIndex/rankIndex table reads the pre-image twice #444

Summary

On any table declaring an aggregateIndex or rankIndex, every db.patch reads the target document twice. The auto-injected write barrier occupies the update.before hook slot, which makes the pre-image re-read unconditionally necessary from the lifecycle's point of view — even though the barrier provably never writes the row.

Measured on current lifecycle.ts:

The 2× is attributable solely to the barrier occupying the before slot.

Root cause

packages/kitcn/src/orm/lifecycle.ts:395-398. The re-read exists because a user before hook may write the row through innerDb, so the post-hook document cannot be trusted. The injected barrier cannot do that — it only probes aggregate_state.

needsDocuments && tableHooks.update?.before is therefore true on every aggregate-indexed table, whether or not the user wrote a hook.

Not fixed by the recent work

packages/kitcn/src/orm/lifecycle.ts is byte-identical between the audit commit 471ec753 and origin/main — git diff is empty and git log 471ec753..origin/main -- lifecycle.ts returns nothing.

• fix(orm): stop re-reading rows the writer already holds #414 changed insert.ts / update.ts / query.ts / returning-count.ts / mutation-utils.ts only.
• fix(orm): stop re-reading per row in FK, CLEARING, and relation probes #420 added transaction-cache.ts, but createOrmTransactionMemo has exactly one consumer — the CLEARING range probe at aggregate-index/runtime.ts:3113 — so it never dedupes the lifecycle pre-image read.

Suggested fix

Capture existing.update?.before before wrapping, and gate the re-read on that rather than on the post-wrap hook. Tables with an aggregateIndex but no user-supplied update.before then fall back to oldDoc.

Alternatively tag the barrier-only wrapper with a symbol meaning "read-only, no re-read needed" and check for it.

~10 lines in lifecycle.ts.

Existing tests

None pin this. packages/kitcn/src/orm/aggregate-index/write-barrier.read-amplification.vitest.ts (added by #420) counts only aggregate_state by_table_status ranges — its own header says so. The pre-image db.get count is unmeasured.

Pin the fix with a read-bound vitest in that file's style: an N-row update on an aggregateIndex table must issue N pre-image reads, not 2N.

Environment

• kitcn 0.32.1
• convex 1.44.0
• verified and measured against origin/main at 14bab503