Skip to content

usockets(win): defer READABLE re-arm past on_open so .end() mid-handshake doesn't hang - #30028

Open
Jarred-Sumner wants to merge 5 commits into
mainfrom
claude/win-tls-end-mid-handshake
Open

usockets(win): defer READABLE re-arm past on_open so .end() mid-handshake doesn't hang#30028
Jarred-Sumner wants to merge 5 commits into
mainfrom
claude/win-tls-end-mid-handshake

context.c: us_poll_change (no _force variant exists)

212d7e8
Select commit
Loading
Failed to load commit list.
Claude / Claude Code Review completed May 1, 2026 in 37m 1s

Code review found 1 important issue

Found 3 candidates, confirmed 2. See review comments for details.

Details

Severity Count
🔴 Important 1
🟡 Nit 0
🟣 Pre-existing 0
Severity File:Line Issue
🔴 Important packages/bun-usockets/src/context.c:776-779 Windows TLS connect: WRITABLE busy-loop during handshake (last_write_failed defeats loop.c disarm)

Annotations

Check failure on line 779 in packages/bun-usockets/src/context.c

See this annotation in the file changed.

@claude claude / Claude Code Review

Windows TLS connect: WRITABLE busy-loop during handshake (last_write_failed defeats loop.c disarm)

The comment here claims that arming WRITABLE when `last_write_failed` is set "costs one harmless on_writable tick and then the regular loop.c writable-disarm clears it" — but `us_internal_ssl_on_writable` (openssl.c:941) re-runs `ssl_update_handshake`, which re-sets `last_write_failed = 1` on `WANT_READ` *before* loop.c:489 evaluates the disarm gate, so WRITABLE is never disarmed and every Windows TLS client connect spins one core at 100% for the duration of the first handshake RTT. Pre-PR (and