mirror of
https://github.com/oven-sh/bun
synced 2026-02-10 10:58:56 +00:00
686998ed3d
## Summary Fixes a panic that occurred when a WebSocket close frame's payload was split across multiple TCP packets. ## The Bug The panic occurred at `websocket_client.zig:681`: ``` panic: index out of bounds: index 24, len 14 ``` This happened when: - A close frame had a payload of 24 bytes (2 byte code + 22 byte reason) - The first TCP packet contained 14 bytes (header + partial payload) - The code tried to access `data[2..24]` causing the panic ## Root Causes 1. **Bounds checking issue**: The code assumed all close frame data would arrive in one packet and tried to `@memcpy` without verifying sufficient data was available. 2. **Premature flag setting**: `close_received = true` was set immediately upon entering the close state. This prevented `handleData` from being called again when the remaining bytes arrived (early return at line 354). ## The Fix Implemented proper fragmentation handling for close frames, following the same pattern used for ping frames: - Added `close_frame_buffering` flag to track buffering state - Buffer incoming data incrementally using the existing `ping_frame_bytes` buffer - Track total expected length and bytes received so far - Only set `close_received = true` after all bytes are received - Wait for more data if the frame is incomplete ## Testing - Created two regression tests that fragment close frames across multiple packets - All existing WebSocket tests pass (`test/js/web/websocket/`) - Verified the original panic no longer occurs ## Related This appears to be the root cause of crashes reported on Windows when WebSocket connections close, particularly when close frames have reasons that get fragmented by the network stack. --- 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude Bot <claude-bot@bun.sh> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Jarred Sumner <jarred@jarredsumner.com>