Bun test runner and promise rejections: should unhandled async errors fail the test?

Context

I'm designing a test suite that relies on Bun's built-in test runner, using its Jest-style glob discovery for .test.ts files alongside source code. Some tests intentionally exercise asynchronous code paths where promises may reject outside an explicit await or try/catch.

Uncertainty

The documented behavior for unhandled promise rejections inside test files appears unspecified. In Node.js, the unhandledRejection event can be observed or configured to crash the process, but it is unclear how Bun's runner maps such rejections onto test results — whether they fail the enclosing test, pass silently, or surface as a separate warning. This matters because the answer determines whether every async helper needs defensive error handling or whether the runner acts as a safety net.

Assume a recent stable Bun release; the experimental --parallel worker mode may also change this behavior compared to the default sequential main-thread execution.

Questions

• Under current Bun versions, does an unhandled promise rejection inside a test file mark that test as failed, or is it ignored?
• Does the behavior differ between default sequential execution and the experimental --parallel flag?
• Is there a supported configuration or event hook to control rejection handling during bun test?