TypeScript stress tests are sequential — no concurrent load testing

[coreyt]

Problem

The TypeScript SDK stress tests (stress mode in sdk-harness) run all operations sequentially on a single thread. This is because the napi-rs native binding calls are synchronous and block the Node.js event loop — there is no way to interleave operations without worker_threads.

An initial attempt to use worker_threads failed because:

1. Vitest runs .ts files directly (no compiled .js), so workers can't find the compiled worker module
2. Atomics.wait on the main thread blocks the event loop, preventing Worker message delivery
3. The receiveMessageOnPort approach worked but workers couldn't resolve the fathomdb module from the worker thread context

Current state

The Rust stress tests use true OS threads (5 writers + 20 readers) and the Python tests use threading.Thread (limited by GIL but still interleaved). The TypeScript tests use a tight sequential loop (write → read → write → read) which exercises the SDK path but not concurrent access patterns.

What concurrent TS stress tests would validate

• Thread safety of the napi-rs binding layer under concurrent worker_threads access
• Correct handling of SQLite's WAL mode from multiple Node.js threads sharing one engine
• No resource leaks when the native engine is accessed from multiple threads

Possible approaches

1. Async napi-rs bindings — convert the sync native calls to #[napi(async)] so the event loop isn't blocked, enabling Promise.all-based concurrency
2. Compiled worker script — add a build step that compiles stress-worker.ts to JS before tests run, then use worker_threads with the compiled file
3. Child process fork — use child_process.fork() with tsx to run worker scripts as separate processes

Option 1 is the most impactful since it would also improve the SDK's general usability (non-blocking operations), but it's a larger change.

Labels

enhancement, testing