`@cloudflare/vitest-pool-workers`: Same-type RPC calls to Durable Objects occasionally arrive out of order

[threepointone]

Summary

When firing multiple stub.rpc() calls on a Durable Object stub without awaiting each one, adjacent calls occasionally swap order in vitest. This does not happen in production, wrangler dev, or vite dev — only in @cloudflare/vitest-pool-workers.

The reordering is non-deterministic: different runs show swaps at different positions, and small N (like 20) sometimes passes. The effect is more pronounced at higher N.

Reproduction

Repo: https://github.com/threepointone/test-do-rpc-fetch-ordering

npm install
npm test

The "rpc calls preserve send order" test will intermittently fail, and "rpc with N=100" fails consistently. Example output:

expected: [..., "call-5", "call-6", ...]
actual:   [..., "call-6", "call-5", ...]

With N=100, multiple swap pairs are scattered throughout the sequence.

For comparison, the same test logic passes reliably when run via wrangler dev or in production:

# wrangler dev — always passes
npx wrangler dev
curl http://localhost:8787/test-rpc-ordering?n=100

# production — always passes
curl https://test-ordering.threepointone.workers.dev/test-rpc-ordering?n=100

Likely Cause

The vitest pool communicates with workerd over a WebSocket transport. The dispatching of individual RPC calls through this transport likely introduces a race condition where adjacent calls can be reordered before they reach workerd's event loop. workerd's InputGate correctly processes them in arrival order, but they arrive in the wrong order.

This is supported by the fact that:

• The swaps are always between adjacent calls (not large jumps)
• The issue is non-deterministic (consistent with a race, not a logic bug)
• Production and wrangler dev (which don't use the WebSocket transport) never exhibit this

Related

There is a separate, more severe ordering bug in workerd itself where mixed stub.rpc() + stub.fetch() calls are always reordered. That is tracked at cloudflare/workerd#6561 and is unrelated to this vitest-specific issue.

[threepointone]

Updated analysis: WebSocket transport is not the cause

After deeper investigation, I want to correct the "Likely Cause" section above. The vitest pool's WebSocket is only used for Vitest orchestration (birpc for test collection, module loading, console logs). When test code calls env.MyDO.get(id).rpc(...), that goes through real workerd JSRPC — the pool doesn't intercept or proxy it. env is literally cloudflare:workers's real env, and Miniflare delegates DO routing entirely to workerd.

What's actually different

The key difference is the caller context:

In wrangler dev / production: The caller is a fresh worker entrypoint (export default { fetch }) with a clean IoContext. When it fires N stub.rpc() calls, those are the only tasks in the KJ event loop. The startRequest() coroutine resumptions happen in strict FIFO order with no contention.

In vitest: The caller is the Runner Durable Object (__VITEST_POOL_WORKERS_RUNNER_DURABLE_OBJECT__) — a long-lived DO whose IoContext also handles:

• A WebSocket to the Node-side pool for Vitest birpc (module loading, logs, test orchestration)
• Patched setTimeout for console batching
• registerHandlerAndGlobalWaitUntil for async cleanup
• Patched transport.invoke via runInRunnerObject for dynamic imports
• no_handle_cross_request_promise_resolution compat flag (allowing promises to resolve across request boundaries)

When test code fires N stub.rpc() calls synchronously, each creates a PromisedWorkerInterface wrapping a startRequest() coroutine. These coroutines all need to resume through the KJ event loop. In the Runner DO's busy event loop (with concurrent Vitest orchestration traffic), other tasks can interleave between adjacent coroutine resumptions, causing two adjacent RPC calls to swap order before they reach the target DO's InputGate.

This explains the observed pattern:

• Adjacent swaps (not large jumps) — the race is between two coroutines scheduled back-to-back, only differing by one event loop slot
• Non-deterministic — depends on whether a Vitest birpc message or other task lands between two adjacent resumptions
• More swaps at higher N — more calls = more chances for interleaving
• Never happens in wrangler dev — clean event loop with no competing tasks

---

This updated analysis was developed in collaboration with Cursor.