perf(db): replace busy-wait spin loop with Atomics.wait in migration lock

[HUQIANTAO]

Problem

The withMigrationLock function in src/lib/db.ts uses a synchronous busy-wait spin loop to implement retry backoff:

const waitMs = 50 + Math.random() * 100;
const waitUntil = Date.now() + waitMs;
while (Date.now() < waitUntil) { /* busy wait — better-sqlite3 is sync */ }

This burns CPU cycles in a tight loop with zero yield. When multiple Next.js build workers contend for the migration lock at startup, each worker spins for 50–150ms, repeatedly polling Date.now(). With a maxWait of 10 seconds and retry-after-spin logic, a contended startup can spike CPU usage and delay server readiness.

Fix

Replace the spin loop with Atomics.wait() on a SharedArrayBuffer. This is a cooperative blocking wait — the OS deschedules the thread instead of busy-polling. Functionally identical timing semantics, zero CPU cost during the wait.

const waitMs = 50 + Math.random() * 100;
Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, waitMs);

Atomics.wait is available in all Node.js versions ≥ 8.10 and is the standard way to implement blocking waits in synchronous contexts where await is not available.

[vercel]

Someone is attempting to deploy a commit to the op7418's projects Team on Vercel.

A member of the Team first needs to authorize it.