pi-plugin's `test` script uses `bun test --parallel` and fails 659/1150 on clean master: TDZ on `Database` from racing the top-level await in shared/sqlite.ts

[iceteaSA]

Summary

packages/pi-plugin's test script is bun test --parallel --timeout 30000. On clean upstream/master that fails 659 of 1150 tests. Dropping --parallel and changing nothing else passes 1149/1150 (1 intentional skip).

$ cd /tmp/mc-upstream-cmp && git rev-parse --short HEAD
dc952bf3

$ bun run --cwd packages/pi-plugin test          # the package's own script, --parallel
 490 pass · 1 skip · 659 fail · 14 errors      Ran 1150 tests across 98 files [4.99s]

$ cd packages/pi-plugin && bun test --timeout 30000    # identical, minus --parallel
 1149 pass · 1 skip · 0 fail                   Ran 1150 tests across 98 files [82.59s]

Same worktree, same tests, one flag apart. Fresh /tmp worktree off master with a real bun install, no fork code involved.

Cause

The failures all carry:

error: [magic-context] storage unavailable: Cannot access 'Database' before initialization..
       Magic Context is disabled for this run; check log for details.

packages/plugin/src/shared/sqlite.ts resolves its backend through a module-level await loadSqliteModule() and exports Database only after that settles (~line 262). Under --parallel, test files are evaluated concurrently, so a test-level dynamic import() can reach Database while that top-level await is still in flight — a temporal dead zone read, not a lock or timing issue.

It manifests as a mass failure rather than a handful because once one worker trips it, storage unavailable disables Magic Context for that run and everything downstream in that worker fails too. Hence the 4.99s parallel run versus 82.59s serial: it is failing fast, not running fast.

Why packages/plugin is unaffected

It already has a serial script and its test does not pass --parallel:

packages/plugin/package.json   "test:serial": "bun install --frozen-lockfile && bun test --timeout 30000"
packages/pi-plugin/package.json "test":       "bun install --frozen-lockfile && bun test --parallel --timeout 30000"

So the plugin package already sidesteps this; pi-plugin has no serial variant to fall back to.

Distinct from #312

#312 is shared-DB busy_timeout contention colliding with bun's 5000ms per-test default — a lock wait, reported as a wall-clock timeout. This is module initialization ordering, reported as a TDZ ReferenceError, and it fails in milliseconds rather than timing out. Different mechanism, different signature; noting it because both surface under concurrent test execution and are easy to conflate.

Impact

Anyone running pi-plugin's documented test command on master sees a red suite with 659 failures that have nothing to do with their change, and the honest signal (serial) requires knowing to bypass the package script. That is a rough first-contribution experience, and it also means the parallel lane cannot catch a real pi regression — it is saturated.

Fix directions

Cheapest is dropping --parallel from the script, at the cost of 5s → 83s. If the parallel speedup is worth keeping, the underlying fix is making Database safe to touch before the backend settles — an accessor that awaits the in-flight load rather than reading the binding directly, so evaluation order stops mattering. A test:serial sibling matching packages/plugin would at least give contributors a trustworthy lane while the ordering question is decided.

Environment

Clean upstream/master dc952bf3, dedicated /tmp worktree, bun install from lockfile, Bun 1.3.14, Linux x64. Reproduced on both the parallel and serial legs back to back on the same tree. No fork code present.