spawnSync: don't run the bun:test timeout callback while the isolated loop is active - #38883
Merged
Claude / Claude Code Review
completed
Aug 15, 2026 in 27m 41s
Code review found 3 potential issues
Found 3 candidates, confirmed 3. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 0 |
| 🟡 Nit | 3 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟡 Nit | src/runtime/api/bun/js_bun_spawn_bindings.rs:2019 |
handle_timeout runs twice on the deferred spawnSync bun:test timeout path |
Annotations
Check warning on line 2019 in src/runtime/api/bun/js_bun_spawn_bindings.rs
claude / Claude Code Review
handle_timeout runs twice on the deferred spawnSync bun:test timeout path
`Execution::handle_timeout` is not kill-only — after `auto_killer.kill()` it unconditionally does `add_result(RefDataValue::Start)` (Execution.rs:332) — so calling it here *and* again inside the deferred `bun_test_timeout_callback` (bun_test.rs:889) enqueues `Start` twice and writes to `result_queue` from inside the isolated loop, which is exactly the runner state the comment above says must be left to `spawn_sync`. The extra `Start` looks idempotent in `step_group` and the second `auto_killer.k
Loading