-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
What versions & operating system are you using?
System:
OS: macOS 26.1
CPU: (10) arm64 Apple M1 Max
Memory: 90.67 MB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 22.17.1 - /Users/timkelty/.nvm/versions/node/v22.17.1/bin/node
npm: 10.9.2 - /Users/timkelty/.nvm/versions/node/v22.17.1/bin/npm
pnpm: 8.15.4 - /opt/homebrew/bin/pnpm
npmPackages:
@cloudflare/unenv-preset: ^2.4.1 => 2.7.12
@cloudflare/vitest-pool-workers: ^0.10.5 => 0.10.13
wrangler: ^4.47.0 => 4.52.1
Please provide a link to a minimal reproduction
https://github.com/timkelty/repro-onunhandlederror
Describe the Bug
The onUnhandledError callback configured in vitest.config.ts is not being invoked when unhandled promise rejections occur during tests using @cloudflare/vitest-pool-workers. This prevents filtering out expected unhandled errors on a per-test basis.
Expected Behavior
According to Vitest documentation, the onUnhandledError callback should be called for each unhandled error, allowing developers to filter out specific errors by returning false. This should work regardless of the worker pool being used.
Actual Behavior
The onUnhandledError callback is never invoked when using @cloudflare/vitest-pool-workers. Unhandled errors are still reported by Vitest, but the callback function is never called, making it impossible to filter out expected errors.
Workaround
Currently, the only workaround is to use dangerouslyIgnoreUnhandledErrors: true globally or via CLI flag:
vitest run test/example.test.ts --dangerouslyIgnoreUnhandledErrorsHowever, this:
- Cannot be scoped to specific tests
- Still shows errors in output (only prevents test failures)
- May mask legitimate unhandled errors in other tests
Use-case
This is particularly problematic when testing retry logic (e.g., with p-retry) where expected network errors are intentionally thrown and caught/retried. These errors are correctly handled by the application code, but Vitest reports them as unhandled rejections because they occur in the worker context before being caught by the retry mechanism.
The onUnhandledError callback would be the ideal solution to filter out these expected errors, but it doesn't work with the Cloudflare Workers pool.
Please provide any relevant error logs
No response
Metadata
Metadata
Assignees
Labels
Type
Projects
Status