test(data): per-scenario state isolation to bound the read fan-out

@data oscillated 15-20/21 because the persistent test wallet accumulated data across scenarios, growing the read fan-out. Add a cheap per-scenario reset (resetDataState): a single SPARQL DELETE on the shim anchor graph clears the account records, so allAccounts() collapses and the fan-out is bounded to what the current scenario re-provisions (accounts recreated lazily). O(1) on one graph — not a fan-out delete (which saturated the browser before). Called in the @data Before hook, time-boxed so it can't starve the broker login budget. Test-infra only — product model, boundary and app read path untouched. Note: not yet re-measured to stable-green — the broker was degraded during the bounded validation window (DNS/timeout flakiness). To re-measure when the broker is stable. knowledge_data-layer-broker updated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-05 13:28:08 +02:00
parent 966ba9855c
commit eafb4403b9
3 changed files with 84 additions and 7 deletions
@@ -578,6 +578,26 @@ Before({ timeout: 60000 }, async function (this: FestipodWorld, scenario) {
        () => (window as any).__testData?.ready === true,
        { timeout: 30000 },
      );
+
+      // PER-SCENARIO STATE ISOLATION (T03.j). The @data suite shares ONE
+      // persistent broker-backed wallet, so the emulated account registry
+      // ACCUMULATES every account any prior scenario/run created — growing the
+      // read fan-out (`allAccounts()` → per-account `listEntityDocs`) until it
+      // gets slow and flaky. Purge the registry anchor once here so each @data
+      // scenario starts from a CLEAN registry and the fan-out stays bounded to
+      // what this scenario re-provisions. A single SPARQL DELETE on ONE graph —
+      // not a fan-out delete.
+      // HARD-BOUNDED (≤10s): this reset shares the Before hook's 60s budget with
+      // the (already slow, intermittent) broker login. It must NEVER contend for
+      // that budget — a slow purge on a hugely-accumulated anchor graph, or a
+      // broker stall, is swallowed and the scenario proceeds (its own steps still
+      // gate on state). So race it against a 10s cap and never let it throw.
+      await Promise.race([
+        this.appFrame.evaluate(async () => {
+          try { await (window as any).__testData?.resetDataState?.(); } catch { /* best-effort */ }
+        }),
+        new Promise((r) => setTimeout(r, 10000)),
+      ]).catch(() => { /* best-effort */ });
    } else {
      // Mock mode: load harness directly
      await this.page!.setContent('<!DOCTYPE html><html><body><div id="root"></div></body></html>');
@@ -366,6 +366,55 @@ function ConnectedHarness() {
          return { cleared: all.length };
        },

+        /**
+         * PER-SCENARIO STATE ISOLATION (T03.j). The @data suite runs against ONE
+         * persistent broker-backed wallet, so the emulated account registry (the
+         * `urn:ng-eventually:shim:Account` triples in the private-store anchor
+         * graph) ACCUMULATES every account any scenario/run ever provisioned. The
+         * read path is a fan-out: `allAccounts()` → one SPARQL SELECT per account
+         * for `listEntityDocs`. As the registry grows unbounded across runs, that
+         * fan-out gets slow and flaky (same class as the T03.d Chromium saturation).
+         *
+         * This gives each @data scenario a CLEAN registry: a SINGLE SPARQL DELETE
+         * on the ONE private-store anchor graph removes every accumulated Account
+         * record, so `allAccounts()` collapses to empty and the fan-out is bounded
+         * to whatever the CURRENT scenario re-provisions (accounts are lazily
+         * re-created by `ensureAccount` on first use). It is O(1) on ONE graph — NOT
+         * a fan-out delete (which saturated the browser before, see T03.i's removed
+         * `authClearParticipation`). Orphaned per-entity docs are simply never
+         * enumerated once their owning Account record is gone.
+         *
+         * Test-infra ONLY: touches the emulation's registry anchor, never the
+         * product model, the app read path, or the boundary. The lib is untouched;
+         * this reuses the same anchor NURI (`did:ng:${private_store_id}`) and shim
+         * vocabulary the lib's `loadShim`/`ensureAccount` use.
+         */
+        async resetDataState() {
+          const reg = await import('../utils/storeRegistry');
+          const priv = `did:ng:${session.private_store_id}`;
+          const SHIM = 'urn:ng-eventually:shim';
+          const t0 = Date.now();
+          // Delete every Account record (and its username/doc* predicates) from the
+          // anchor graph. `?p ?o` with the `a shim:Account` guard scopes the delete
+          // strictly to registry triples, leaving anything else in the private
+          // store intact.
+          const del = `
+            DELETE { GRAPH <${priv}> { ?acc ?p ?o } }
+            WHERE {
+              GRAPH <${priv}> {
+                ?acc a <${SHIM}:Account> ;
+                     ?p ?o .
+              }
+            }`;
+          try {
+            await docs.sparqlUpdate(session.session_id, del, priv);
+          } catch { /* best-effort — a broker flake must not fail the scenario */ }
+          // Drop the in-memory account cache so the next registry call re-reads the
+          // now-empty anchor (else a stale cache would keep the old accounts alive).
+          reg.resetRegistryCache();
+          return { resetMs: Date.now() - t0 };
+        },
+
        /** ONE-TIME CLEANUP (T03.i): the private store accumulated thousands of
         *  historical inbox-deposit triples across test runs (the old inbox anchor
         *  = private store), making `loadShim` a 60s+ full-graph scan. Delete every