`storage-embedding-measurements` cap test does 2005 disk-backed inserts with no declared timeout — fails on slower hardware

[iceteaSA]

Summary

embedding measurement corpus > bounds a session's corpus rows, keeping the newest when the cap is exceeded times out at bun's default 5000 ms on my machine. It reproduces on clean upstream/master, in isolation, so it is not a fork regression and not the cross-file contention from #312.

$ cd packages/plugin && bun test src/features/magic-context/storage-embedding-measurements.test.ts
 1 pass
 1 fail          ← ^ this test timed out after 5000ms
Ran 2 tests across 1 file. [7.91s]

Verified on a pristine git archive upstream/master extraction with a fresh bun install --frozen-lockfile. Our fork's tree gives 7.85 s against upstream's 7.91 s — same failure, same timing, so the fork is not implicated.

Cause

storage-embedding-measurements.test.ts:58-88 loops MEASUREMENT_CORPUS_SESSION_ROW_CAP + 5 times — the constant is 2000, so 2005 iterations — each calling recordEmbeddingMeasurement against a real on-disk SQLite database (XDG_DATA_HOME pointed at an mkdtempSync dir, opened via openDatabase()).

Measured cost is ~3.7 ms per insert here, so ~7.4 s of real work against a 5000 ms default. The test declares no timeout, so its verdict is a function of machine speed rather than of behavior.

Worth noting as a repo-wide observation rather than a one-test issue: grep -c '}, [0-9]\{4,\});' src/**/*.test.ts returns 0 — no test in the plugin package declares an explicit timeout, and bunfig.toml sets none. So every long test inherits 5000 ms silently. This one is simply the first to cross it.

Why it isn't #312

#312 is cross-file lock contention: many test files share one context.db, PRAGMA busy_timeout is 5000 ms, and bun's default per-test timeout is also 5000 ms, so a lock wait and the test kill expire together. That mechanism requires concurrency.

This one reproduces with a single file, a single test, and its own temp XDG_DATA_HOME — no second writer, no lock wait. The cause here is raw work volume against an undeclared timeout. Same symptom (5000 ms), unrelated mechanism.

Suggested fix

Either is cheap; the first is narrower:

1. Declare a timeout on this test — it("bounds a session's corpus rows…", () => { … }, 30_000). Honest about the work it does, and makes the verdict hardware-independent.
2. Make the cap injectable for tests so the loop can exercise the eviction boundary with, say, 25 rows instead of 2005. The test is verifying "keeps the newest when the cap is exceeded", which is a boundary property — it does not need the production cap value to prove it.

(2) is the better long-term shape: it tests the same invariant in ~90 ms instead of ~7.4 s, and removes the hardware dependence entirely rather than raising the ceiling above it.

Environment

• Reproduced on clean upstream/master (v0.38.0) and on our fork, both with bun install --frozen-lockfile
• Linux, bun 1.3.14
• Passes in your CI, so this is hardware-dependent by nature — which is the point: the test's outcome should not depend on that

[coleleavitt]

Fixed by PR #338: the 2,005-row embedding-measurement fixture now inserts inside one SQLite transaction. The prior default-timeout failure is covered by the targeted regression and CI.