Issue Review: cloudflare/workers-sdk#7707

Summary

Errors thrown from Durable Object RPC methods cause vitest-pool-workers to crash with "unhandled error" instead of being caught by test assertions.

Findings

• Created: 2025-01-08
• Updated: 2025-10-30
• Version: wrangler 3.100.0, Node 20.11.1 -> wrangler 4.60.0
• Component: vitest-pool-workers, Durable Objects
• Labels: bug, vitest
• Comments: 1 (user asking for workaround)

Key Evidence

• Minimal reproduction repo provided: https://github.com/its-jman/rpc-error-repro
• Issue: When DO RPC method throws an error, vitest catches it as "unhandled error" instead of allowing test assertions to handle it
• Expected: RPC errors should propagate to test code per CF docs on RPC error handling
• Actual: "Vitest caught 1 unhandled error during the test run" + "Failed to pop isolated storage stack frame"
• One commenter (June 2025) asking for workaround, noting this makes integration testing "completely impossible"
• No PRs found fixing this specific issue
• Not mentioned in changelogs

Recommendation

Status: KEEP OPEN

Reasoning: This is a valid bug with a clear reproduction. RPC errors from Durable Objects should be catchable in test code, but vitest-pool-workers treats them as unhandled errors. This significantly impacts the testability of DO-based workers that use RPC. The issue has user engagement (comment + 4 emoji reactions) and a reproduction repo.

Action: Keep open for vitest-pool-workers team to investigate how RPC errors are propagated through the test harness. May require changes to error handling in the isolated runtime communication layer.

Suggested Comment

Thanks for the detailed reproduction. This is a valid bug affecting testing of Durable Objects with RPC methods that can throw errors.

The issue appears to be in how vitest-pool-workers handles errors propagating across the RPC boundary between the test runner and the isolated DO runtime.

As a temporary workaround, you might consider wrapping your DO RPC calls in try-catch and returning error objects rather than throwing:

async myCustomFunc() { 
  try {
    // ... implementation
  } catch (e) {
    return { error: e.message };
  }
}

Keeping this open for investigation.