The key issue was understanding how uWebSockets handles WebSocket routes:
When app.ws() is called, it internally registers a GET handler that:
1. Checks for WebSocket upgrade headers (sec-websocket-key)
2. If present → handles WebSocket upgrade via the upgrade callback
3. If absent → calls req->setYield(true) to pass to next handler
This means app.ws() must be registered BEFORE app.method(.GET) for the
same path, so that:
- WebSocket requests → handled by app.ws()
- Regular GET requests → yield and fall through to GET handler
Changes:
- Register upgrade handler FIRST in user_routes_to_build (before method handlers)
- This ensures correct registration order in server.zig
- Removed websocket_only enum variant (not needed with correct ordering)
- Updated test to expect error on server creation (not connection time)
- Validate that route websocket requires upgrade handler
All 8 tests now passing:
✓ route-specific websocket handlers work independently
✓ route-specific websocket with data in upgrade
✓ route-specific websocket with close handler
✓ global websocket handler still works
✓ mix of route-specific and global websocket handlers
✓ route-specific websocket with multiple HTTP methods
✓ route-specific websocket without upgrade handler errors
✓ server.reload() preserves route-specific websocket handlers
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implements support for per-route WebSocket handlers in Bun.serve() routes.
Routes can now specify their own websocket configuration:
```js
Bun.serve({
routes: {
"/api/v1/chat": {
websocket: {
open(ws) { ws.send("chat:welcome"); },
message(ws, data) { ws.send("chat:" + data); },
},
upgrade(req, server) {
return server.upgrade(req);
},
},
"/api/v2/notifications": {
websocket: {
open(ws) { ws.send("notif:connected"); },
message(ws, data) { ws.send("notif:" + data); },
},
upgrade(req, server) {
return server.upgrade(req);
},
},
},
});
```
Implementation details:
- Added route_websocket_contexts ArrayList to server to store per-route WebSocket contexts
- WebSocket routes use id >= 2 (id - 2 = index in route_websocket_contexts array)
- id == 1 continues to mean global WebSocket handler
- id == 0 continues to mean fallback route
- Updated route parsing in ServerConfig to extract websocket field from route objects
- Modified onUpgrade() to select correct WebSocket handler based on route context index
- Properly handles server.reload() by rebuilding route WebSocket contexts
- Global websocket handler continues to work alongside route-specific handlers
Tests cover:
- Independent route-specific WebSocket handlers
- WebSocket upgrade with custom data
- Close handlers
- Mix of global and route-specific handlers
- server.reload() preservation
- 7/8 tests passing (one test with multiple HTTP methods needs investigation)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
`ZigString.Slice.cloneIfNeeded` does *not* guarantee that the returned
slice will have been allocated by the provided allocator, which makes it
very easy to use this method incorrectly.
(For internal tracking: fixes ENG-21284)
Add a new generator for JS → Zig bindings. The bulk of the conversion is
done in C++, after which the data is transformed into an FFI-safe
representation, passed to Zig, and then finally transformed into
idiomatic Zig types.
In its current form, the new bindings generator supports:
* Signed and unsigned integers
* Floats (plus a “finite” variant that disallows NaN and infinities)
* Strings
* ArrayBuffer (accepts ArrayBuffer, TypedArray, or DataView)
* Blob
* Optional types
* Nullable types (allows null, whereas Optional only allows undefined)
* Arrays
* User-defined string enumerations
* User-defined unions (fields can optionally be named to provide a
better experience in Zig)
* Null and undefined, for use in unions (can more efficiently represent
optional/nullable unions than wrapping a union in an optional)
* User-defined dictionaries (arbitrary key-value pairs; expects a JS
object and parses it into a struct)
* Default values for dictionary members
* Alternative names for dictionary members (e.g., to support both
`serverName` and `servername` without taking up twice the space)
* Descriptive error messages
* Automatic `fromJS` functions in Zig for dictionaries
* Automatic `deinit` functions for the generated Zig types
Although this bindings generator has many features not present in
`bindgen.ts`, it does not yet implement all of `bindgen.ts`'s
functionality, so for the time being, it has been named `bindgenv2`, and
its configuration is specified in `.bindv2.ts` files. Once all
`bindgen.ts`'s functionality has been incorporated, it will be renamed.
This PR ports `SSLConfig` to use the new bindings generator; see
`SSLConfig.bindv2.ts`.
(For internal tracking: fixes STAB-1319, STAB-1322, STAB-1323,
STAB-1324)
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Alistair Smith <hi@alistair.sh>
Replace `catch bun.outOfMemory()`, which can accidentally catch
non-OOM-related errors, with either `bun.handleOom` or a manual `catch
|err| switch (err)`.
(For internal tracking: fixes STAB-1070)
---------
Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
## Summary
Fixes a prerequisite issue in #21792 where `Bun.serve()` incorrectly
rejected TLS arrays with exactly 1 object.
The original issue reports a WebSocket crash with multiple TLS configs,
but users first encounter this validation bug that prevents
single-element TLS arrays from working at all.
## Root Cause
The bug was in `ServerConfig.zig:918` where the condition checked for
exactly 1 element and threw an error:
```zig
if (value_iter.len == 1) {
return global.throwInvalidArguments("tls option expects at least 1 tls object", .{});
}
```
This prevented users from using the syntax: `tls: [{ cert, key,
serverName }]`
## Fix
Updated the validation logic to:
- Empty TLS arrays are ignored (treated as no TLS)
- Single-element TLS arrays work correctly for SNI
- Multi-element TLS arrays continue to work as before
```zig
if (value_iter.len == 0) {
// Empty TLS array means no TLS - this is valid
} else {
// Process the TLS configs...
}
```
## Testing
- ✅ All existing SSL tests still pass (16/16)
- ✅ New comprehensive regression test with 7 test cases
- ✅ Tests cover empty arrays, single configs, multiple configs, and
error cases
## Note
This fix addresses the validation issue that prevents users from
reaching the deeper WebSocket SNI crash mentioned in #21792. The crash
itself may require additional investigation, but this fix resolves the
immediate blocker that users encounter first.
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
