Sylvain Duchesne
ffa1f94206
Cause racine mesurée (broker réel, access-log) : à la première resolveAccount d'une session, le record de compte tout juste persisté (ou d'une session antérieure) peut lire 0 lignes à cause du LAG DE SYNC broker. ensureAccount interprétait ce 0 comme « compte inexistant » et RE-PROVISIONNAIT un second jeu de docs de scope (docPublic/docProtected forkés) → les lectures d'une session tombaient sur un jeu, celles d'une autre (ou après drop de cache) sur l'autre jeu vide → données « perdues » à la reconnexion. Fix : `resolveAccountReliably` (store-registry.ts) — retry borné (ouverture du repo d'ancre shim + backoff plafonné, défaut 8 tentatives / ≲8.5s) AVANT que ensureAccount ne décide qu'un compte est neuf. Provisionne seulement si, après le budget, la lecture rend toujours 0 (compte réellement neuf). Budget injecté via StoreRegistryDeps.provisionRetry (polyfill.ts), ON en prod ; tests unitaires à provisionRetry synchrone (attempts:1, fake sans lag). Idempotence de session préservée par accountCache (hit court-circuite, déterministe). Portée : corrige le déterminisme de provisioning. NE suffit PAS à réparer la reconnexion (le read public à 0 same-session subsiste, cause distincte encore à mesurer de façon déterministe — le lag broker rend les mesures non-reproductibles). Complémentaire du commit open-repo précédent, pas redondant. gate : tsc --noEmit propre ; bun test 91 pass ; auth @data (vide/distinctes) verts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ng-eventually/client
Two entry points — the data-plane is SDK-identical, the polyfill bootstrap is separate:
| Import | Surface |
|---|---|
@ng-eventually/client |
The same signature as the SDK — ng, useShape, inbox (+ types). A drop-in for @ng-org/web / @ng-org/orm; as NextGraph matures it resolves to the real SDK (build alias removed) with no code change. |
@ng-eventually/client/polyfill |
The only non-SDK surface — configure, setCurrentUser, and capability helpers (getCaps, grantRead, canRead/canWrite). It falls away as NextGraph matures. |
// bootstrap (the only non-SDK call) — inject the real SDK
import { configure } from "@ng-eventually/client/polyfill";
configure({ ng: realNg, useShape: realUseShape, sharedWallet, currentUser });
// from here on, a pure SDK surface:
import { ng, useShape, inbox } from "@ng-eventually/client";
await ng.doc_create(/* … */);
const set = useShape(MyShape, scope); // filtered to what the identity may read
await inbox.post(targetInbox, ref); // deposit (anticipated SDK API)
What the polyfill adds on top of the real SDK (each emulated for now, native as NextGraph matures):
- Shared-wallet identity (one wallet for everyone; the current identity id is relayed to the SDK).
- Capability enforcement — a read filter + write guard over emulated grants attached to documents; the app declares a document's read policy and issues directed read grants.
- Anticipated methods (inbox
post, capability ops) with their future-SDK shapes, emulated for now.
Generic: no application domain. The consumer application injects its shapes and performs the acts of granting access. The relationship concept ("who is connected to whom") is the consumer application's own — the client exposes only directed per-document read grants.