win: high-resolution event-loop timer via waitable timer + IOCP - #34834
Merged
Claude / Claude Code Review
completed
Jul 20, 2026 in 10m 35s
Code review found 2 potential issues
Found 5 candidates, confirmed 2. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 0 |
| 🟡 Nit | 2 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟡 Nit | patches/libuv/win-hrtimer.patch:186-188 |
hrtimer handles leak on uv_loop_init failure paths |
| 🟡 Nit | test/js/web/timers/setTimeout.test.js:561 |
Test asserts stderr is exactly empty (breaks under ASAN/debug) |
Annotations
Check warning on line 188 in patches/libuv/win-hrtimer.patch
claude / Claude Code Review
hrtimer handles leak on uv_loop_init failure paths
`uv__hrtimer_init` creates two kernel HANDLEs (`lfields->hrtimer` and `lfields->hrtimer_pkt`) before the remaining fallible steps in `uv_loop_init` (timer_heap malloc, `uv_mutex_init(&loop->wq_mutex)`, `uv_async_init`, `uv__loops_add`), whose `fail_*` unwind ladder `uv__free(lfields)` without closing either handle — `uv__loop_close` is not called when init fails. Practically these paths are OOM-only so it won't matter in production, but the trivial fix is to move the `uv__hrtimer_init(loop, lfie
Check warning on line 561 in test/js/web/timers/setTimeout.test.js
claude / Claude Code Review
Test asserts stderr is exactly empty (breaks under ASAN/debug)
`expect(stderr).toBe("")` will flake under ASAN/debug builds, which emit benign warnings to stderr — REVIEW.md explicitly forbids asserting stderr is exactly empty. Filter the known-benign lines first (see the `filteredStderr` pattern used a few lines up in this same file) or fold stderr into a combined `{ stdout, stderr, exitCode }` assertion.
Loading