@ai-matrx/records 0.86.2 → 0.87.2

package/dist/index.d.cts

@@ -364,40 +364,6 @@ type MergeFieldResolution = {
     reason: string;
 };
 
-/**
- * THE CLIENT OPERATION LEDGER — how a browser recognises the echo of its own write.
- *
- * Every private-channel notice the record store broadcasts reaches EVERY browser watching that
- * Table, including the one that caused it. Until now the writer had no way to tell its own
- * change from a colleague's: the notice carried ids and nothing about who moved them, so
- * `recordsRealtimePort.ts` declared `acceptEchoFromSelf: true` and the writer re-read a page it
- * had already updated. It was named honestly rather than faked, and this is the other half.
- *
- * THE SHAPE. Every write through `RecordsClient` mints a uuid, sends it to the store as the
- * platform envelope key `_op_id`, and remembers it here. The store lifts that key out before
- * storage — it is never written onto the record — carries it on the change-feed row, and puts
- * it in the notice as `op_id`. A notice whose `op_id` is in this ledger is this browser's own
- * echo and is dropped.
- *
- * WHY A TIME WINDOW RATHER THAN A DELETE-ON-MATCH. One write can produce MORE THAN ONE notice:
- * a record write that also moves a column produces a `record` notice and a `field` notice, and
- * a statement touching two Tables produces one per Table. Forgetting an op the first time it
- * came back would make the second notice look like somebody else's and cost the re-read this
- * exists to avoid. So an op is remembered for a window and expires on its own.
- *
- * 🚨 THE WINDOW IS A CORRECTNESS BOUNDARY, NOT A TUNING KNOB, AND IT FAILS IN THE SAFE
- * DIRECTION BY CONSTRUCTION. Too SHORT and a late echo is treated as a stranger's change: one
- * extra read of a page that is already correct — invisible. Too LONG and a stranger's change
- * that happened to reuse our uuid would be dropped — which cannot happen, because it is a v4
- * uuid nobody else has ever seen. The only real cost of a long window is memory, so it is
- * bounded by COUNT as well as by time.
- *
- * WHAT THIS IS NOT. It is not a replacement for the store's optimistic concurrency, and it
- * never decides what is true — a dropped echo means "I already know about this", and every
- * path that could be wrong about that (a reconnect, a tab wake, a notice with no `op_id` at
- * all) re-reads through the door as it always did.
- */
-
 /**
  * Mint the id for one client operation and remember it as ours.
  *

package/dist/index.d.ts

@@ -364,40 +364,6 @@ type MergeFieldResolution = {
     reason: string;
 };
 
-/**
- * THE CLIENT OPERATION LEDGER — how a browser recognises the echo of its own write.
- *
- * Every private-channel notice the record store broadcasts reaches EVERY browser watching that
- * Table, including the one that caused it. Until now the writer had no way to tell its own
- * change from a colleague's: the notice carried ids and nothing about who moved them, so
- * `recordsRealtimePort.ts` declared `acceptEchoFromSelf: true` and the writer re-read a page it
- * had already updated. It was named honestly rather than faked, and this is the other half.
- *
- * THE SHAPE. Every write through `RecordsClient` mints a uuid, sends it to the store as the
- * platform envelope key `_op_id`, and remembers it here. The store lifts that key out before
- * storage — it is never written onto the record — carries it on the change-feed row, and puts
- * it in the notice as `op_id`. A notice whose `op_id` is in this ledger is this browser's own
- * echo and is dropped.
- *
- * WHY A TIME WINDOW RATHER THAN A DELETE-ON-MATCH. One write can produce MORE THAN ONE notice:
- * a record write that also moves a column produces a `record` notice and a `field` notice, and
- * a statement touching two Tables produces one per Table. Forgetting an op the first time it
- * came back would make the second notice look like somebody else's and cost the re-read this
- * exists to avoid. So an op is remembered for a window and expires on its own.
- *
- * 🚨 THE WINDOW IS A CORRECTNESS BOUNDARY, NOT A TUNING KNOB, AND IT FAILS IN THE SAFE
- * DIRECTION BY CONSTRUCTION. Too SHORT and a late echo is treated as a stranger's change: one
- * extra read of a page that is already correct — invisible. Too LONG and a stranger's change
- * that happened to reuse our uuid would be dropped — which cannot happen, because it is a v4
- * uuid nobody else has ever seen. The only real cost of a long window is memory, so it is
- * bounded by COUNT as well as by time.
- *
- * WHAT THIS IS NOT. It is not a replacement for the store's optimistic concurrency, and it
- * never decides what is true — a dropped echo means "I already know about this", and every
- * path that could be wrong about that (a reconnect, a tab wake, a notice with no `op_id` at
- * all) re-reads through the door as it always did.
- */
-
 /**
  * Mint the id for one client operation and remember it as ours.
  *

package/dist/index.js

@@ -2151,9 +2151,10 @@ function sourceArchivedOf(value) {
 }
 
 // src/ops.ts
+import { globalSlot } from "@ai-matrx/kit/global-slot";
 var REMEMBER_MS = 3e4;
 var REMEMBER_MAX = 500;
-var ours = /* @__PURE__ */ new Map();
+var ours = globalSlot("ai-matrx.records.op-ledger", () => /* @__PURE__ */ new Map());
 function trim(now) {
   for (const [id, at] of ours) {
     if (now - at <= REMEMBER_MS) break;