spawnSync: don't run the bun:test timeout callback while the isolated loop is active

Merged
JA
3mo ago
+53-39

What does this PR do?

test/regression/issue/07261.test.ts has been hanging in the bun test --parallel batch on the glibc Linux lanes (17 of the last ~110 PR builds; passes when retried alone). In the shard log the batch goes quiet with 07261 as the only file left, the 90s per-test deadline passes with no (fail) … timed out line ever printed, and the runner's idle timeout kills the batch 4 minutes later. A live capture of a hung batch shows the worker running the file spinning at 100% CPU with no syscalls, its spawnSync child a zombie, the pidfd still open.

When the per-test deadline passed while Bun.spawnSync was blocking, the sync wait loop called BunTest::bun_test_timeout_callback in place — re-entering the whole test runner (result queue, handle_test_completed, junit, worker IPC, timer heap) while vm.event_loop_handle still pointed at the isolated loop and before the child had been reaped. Nothing outside the sync child's own I/O should run there.

Now the loop only calls Execution::handle_timeout (kill the dangling processes so the child dies and the wait drains, killed N dangling process is still printed at the deadline) and hands the deadline back to spawn_sync, which fires the runner's callback once spawn_maybe_sync has torn the isolated loop down. If an exception is pending by then (spawn failure, termination), the file timer is left armed and reports the timeout from the main loop; an exception raised by the deferred callback is propagated (Ok(JSValue::ZERO) with the exception on the global, same as the existing post-loop path). Only src/runtime/api/bun/js_bun_spawn_bindings.rs changes.

How did you verify your code works?

  • test/cli/test/test-timeout-behavior.test.ts (sync fixture: spawnSync outliving the per-test timeout still prints killed 1 dangling process, (fail) …, no JavaScript execution terminated, and the next test runs), test/js/bun/spawn/spawnSync.test.ts, spawnsync-no-microtask-drain, spawn-signal, spawn-maxbuf, bun-test.test.ts -t timeout, parallel.test.ts (33/35; the unique JEST_WORKER_ID failure is the known debug-build timing flake noted in #38442) — on the debug build of this branch.
  • The CI hang itself only reproduced under host load in a Linux container with the CI binary (~1/100 batches); there is no deterministic test for it in this PR. I'll re-run that stress against this branch's Linux CI build and post the counts here.