Stabilize flaky host-selfhost integration tests (#1208)

These suites each boot a full self-host app graph and drive it over the
in-memory handler; scope-isolation additionally fired 48 unbounded concurrent
requests through the single shared libSQL connection. Run in parallel forks
sized to the core count, many heavy boots oversubscribe the CPU and starve the
event loop, so an in-flight request stalls and the test times out. Which file
loses the race is nondeterministic, which is what showed up as CI flakiness.

Bound both sources of concurrency rather than leaning on timing:

- vitest.config: cap the fork pool at 2 and raise the test/hook timeouts to
  30s, so the package stays parallel but never oversubscribes regardless of how
  many cores the machine has (a many-core dev box oversubscribes harder than a
  4-vCPU CI runner).
- scope-isolation: read the 6 identities back in bounded rounds (6 in flight,
  repeated) instead of a 48-wide burst. Same 48 reads and the same disjointness
  assertions, without piling 48 fibers onto the one serialized connection.

Verified green across repeated full-suite runs under heavy local load.

Author: RhysSullivan

apps/host-selfhost/src/scope-isolation.test.ts

@@ -92,8 +92,17 @@ const listConnectionAddresses = async (
 };
 
 test("concurrent requests with distinct identities get disjoint, correct executor bindings", async () => {
-  // 6 identities, each its own (org, user). Seed each sequentially, then fire 48
-  // interleaved reads over the one long-lived SQLite handle.
+  // 6 identities, each its own (org, user). Seed each sequentially, then read
+  // them back over the one long-lived SQLite handle with all 6 distinct
+  // identities in flight at once, repeated across rounds.
+  //
+  // The leak this guards against is a logic bug (a shared rather than
+  // request-scoped binding), so it surfaces whenever distinct identities are
+  // concurrent at all; 6 simultaneous is plenty. We deliberately bound
+  // in-flight requests to those 6 instead of firing an unbounded 48-wide burst:
+  // every query serializes through the single libSQL connection, so a 48-fiber
+  // pile-up starves the event loop under CI load and times out (the flake this
+  // test was hitting). Same 48 total reads, same assertions, bounded pressure.
   const identities = Array.from({ length: 6 }, (_, i) => ({
     userId: `user-${i}`,
     organizationId: `org-${i}`,
@@ -103,23 +112,30 @@ test("concurrent requests with distinct identities get disjoint, correct executo
     await seedIdentity(id.userId, id.organizationId);
   }
 
-  const requests = Array.from({ length: 48 }, (_, i) => identities[i % identities.length]);
-  const results = await Promise.all(
-    requests.map((id) => listConnectionAddresses(id.userId, id.organizationId)),
-  );
+  const rounds = 8;
+  const observed: Array<{ userId: string; status: number; addresses: string[] }> = [];
+  for (let round = 0; round < rounds; round++) {
+    const roundResults = await Promise.all(
+      identities.map(async (id) => ({
+        userId: id.userId,
+        ...(await listConnectionAddresses(id.userId, id.organizationId)),
+      })),
+    );
+    observed.push(...roundResults);
+  }
 
-  results.forEach((result, i) => {
-    const { userId } = requests[i];
+  expect(observed).toHaveLength(rounds * identities.length);
+  observed.forEach(({ userId, status, addresses }) => {
     // Each response reflects ONLY its own request's identity — no bleed. The
     // subject's own user connection is present, and no OTHER subject's is.
-    expect(result.status).toBe(200);
-    expect(result.addresses.some((a) => a.includes(connectionNameForUser(userId)))).toBe(true);
+    expect(status).toBe(200);
+    expect(addresses.some((a) => a.includes(connectionNameForUser(userId)))).toBe(true);
     const otherUsers = identities.map((id) => id.userId).filter((u) => u !== userId);
     for (const other of otherUsers) {
-      expect(result.addresses.some((a) => a.includes(connectionNameForUser(other)))).toBe(false);
+      expect(addresses.some((a) => a.includes(connectionNameForUser(other)))).toBe(false);
     }
   });
-}, 15_000);
+}, 30_000);
 
 test("a request with no identity is rejected", async () => {
   const res = await handler(new Request("http://localhost/api/connections"));

apps/host-selfhost/vitest.config.ts

@@ -4,5 +4,30 @@ export default defineConfig({
   test: {
     include: ["src/**/*.test.ts"],
     passWithNoTests: true,
+    // These are integration suites: most boot a full self-host app graph
+    // (Better Auth + libSQL + MCP + plugins) at module load, then drive it
+    // over the in-memory handler, and some (scope-isolation) fire dozens of
+    // concurrent requests through it. Each boot is CPU-heavy and every query
+    // serializes through the one shared libSQL connection, so when many files
+    // boot at once they oversubscribe the CPU and starve the event loop: an
+    // in-flight request stalls indefinitely and the test times out. Which
+    // files lose the race is nondeterministic, which is the CI flakiness.
+    //
+    // Vitest sizes its fork pool to the core count, so a many-core machine
+    // oversubscribes HARDER than a small CI runner. Bound the concurrency to
+    // an absolute number instead, so behavior is the same everywhere: at most
+    // two heavy boots run together, which fits a 4-vCPU runner without
+    // starvation while still running the suite in parallel. Pair it with
+    // integration-grade timeouts as headroom for the slowest boot. This keeps
+    // every assertion intact (no logic or coverage changed) and makes the
+    // suite deterministic rather than load-dependent.
+    testTimeout: 30_000,
+    hookTimeout: 30_000,
+    poolOptions: {
+      forks: {
+        maxForks: 2,
+        minForks: 1,
+      },
+    },
   },
 });