partyserver@0.5.10

Patch Changes

• #417 5ce45b7 Thanks @threepointone! - Inherit hibernation settings when a Server subclass declares partial static options.

partyserver@0.5.9

Patch Changes

• #415 1eb112f Thanks @mattzcarey! - Allow @cloudflare/workers-types v5 as a peer dependency. PartyServer remains compatible with v4 while projects using Wrangler 4.108 and newer can install the v5 runtime types without a peer dependency conflict.

partysocket@1.3.0

Minor Changes

• #409 6b97742 Thanks @threepointone! - Add shouldReconnectOnClose, allowing callers to stop automatic reconnects for terminal close events while preserving the existing reconnect-by-default behavior.

partyserver@0.5.8

Patch Changes

• #407 2be6104 Thanks @threepointone! - Encode the x-partykit-props header as base64 so props containing non-ASCII characters (e.g. accented names like "Usuário") no longer trigger workerd's "header value contains non-ASCII characters" warning, which would throw a TypeError in browser fetch implementations. The header is decoded back to the original Unicode payload on the server, and raw-JSON values from older callers are still accepted for backwards compatibility.

partyserver@0.5.7

Patch Changes

• #405 7dbf92c Thanks @threepointone! - Accept non-hibernating WebSocket connections in half-open mode (accept({ allowHalfOpen: true })).

  On compatibility dates >= 2026-04-07 the web_socket_auto_reply_to_close flag makes the runtime send a reciprocal Close frame and tear the socket down automatically. For a non-hibernating PartyServer (hibernate: false), the Durable Object sits on the server end of a connection that the runtime tunnels back to the client, so that auto-teardown could fire through an already-severed tunnel — surfacing as a spurious retryable Network connection lost. rejection (for example when a Durable Object is reset while a connection is still open). Half-open mode keeps PartyServer's existing close handling in control; it already reciprocates the peer's Close frame on every compatibility date, so client behavior is unchanged.

  Also in this release, two related WebSocket fixes that keep behavior consistent across all compatibility dates:

  • Pin binaryType to "arraybuffer" for non-hibernating connections. On compatibility dates >= 2026-03-17 the websocket_standard_binary_type flag flips the default server-side binaryType from "arraybuffer" to "blob", so binary frames arrived as Blob instead of ArrayBuffer on the in-memory path. PartyServer (and frameworks built on it, e.g. Cloudflare Agents) have always received ArrayBuffer, so it is now pinned back in accept(). This is a no-op on older dates and corrective on newer ones; the Hibernation API is unaffected (it always delivers ArrayBuffer).
  • Stop reporting transport-teardown errors as onError. A retryable Network connection lost. / WebSocket peer disconnected error that fires on an already closing/closed connection is the socket going away during the close handshake, not an application error. It is now suppressed when the connection is CLOSING/CLOSED (detected via the structured retryable flag, with a message fallback), so it no longer spams logs on abrupt client disconnects. Genuine mid-connection (OPEN) errors still reach onError.

partysocket@1.2.0

Minor Changes

• #403 7e042eb Thanks @threepointone! - Make buffered messages and connection teardown reliable across socket replacement and explicit close (see cloudflare/agents#1738).

  • close() now dispatches its close event synchronously (mirroring how reconnect() already dispatched its synthetic close). Consumers that detach their listeners right after closing — like the React hooks during cleanup — previously never observed the terminal close event, leaving "connection closed" handling (pending-call rejection, state resets) to never run. After close() returns, readyState reports CLOSED immediately, even while the underlying socket finishes its closing handshake. Code that attached a close listener after calling close() and relied on the event arriving asynchronously must attach the listener first.
  • send() now returns a boolean: true if the message was transmitted immediately over an open connection, false if it was buffered (delivered when the connection next opens, always before the open event is dispatched) or dropped because maxEnqueuedMessages was reached. Callers implementing request/response protocols can use this to know whether a request is actually in flight.
  • New drainQueuedMessages() method removes and returns all messages that were buffered by send() but never transmitted, so a socket that's being discarded can hand its unsent buffer to a replacement instead of silently losing it.
  • React hooks (usePartySocket, useWebSocket) now migrate buffered messages when they replace the socket because connection options changed. By default, buffered messages transfer only when the destination is unchanged (e.g. only query — credentials — changed); if destination options (room, party, path, host, URL, ...) changed, the messages are discarded with a warning rather than delivered to a destination they weren't composed for. The new transferEnqueuedMessages option overrides this: true always transfers, false never does.
  • Warn when send() is called after close(). Messages sent against a permanently closed socket are buffered into a queue that nothing will ever flush (unless reconnect() is called later), which silently strands the message — and any caller waiting on a reply. This usually indicates a stale socket reference in the caller. The message is still buffered for backwards compatibility; the warning is emitted once per close cycle and resets on reconnect().

partysocket@1.1.19

Patch Changes

• #397 798aae5 Thanks @agcty! - fix(partysocket): avoid module-scope random default

partyserver@0.5.6

Patch Changes

• #399 f772382 Thanks @threepointone! - Retry transient Durable Object routing errors from routePartykitRequest and getServerByName, and expose route-level retry configuration.

partyserver@0.5.5

Patch Changes

• #394 9a927a3 Thanks @threepointone! - Don't reciprocate the WebSocket close handshake when the runtime delivers a reserved close code (1005, 1006, 1015). These codes are synthesized by the runtime when the peer didn't actually send a Close frame — there is no handshake to complete. The earlier 0.5.4 change ([#393](https://github.com/cloudflare/partykit/issues/393)) normalized these to 1000 and tried to send a reciprocating Close frame anyway; in cross-isolate transports (notably WebSocket pairs that flow back through Durable Object RPC, e.g. Cloudflare Agents sub-agents) the reciprocation would succeed synchronously but schedule an outbound write on a transport whose peer was already gone. The runtime then rejected that write asynchronously with Network connection lost, escaping closeQuietly's synchronous try/catch and surfacing as an unhandled promise rejection in tests and production logs. The fix is to skip the reciprocation for reserved codes — there's nothing to acknowledge to a peer that didn't speak. The narrow user-visible behavior change: a client that calls ws.close() with no code on compat dates < 2026-04-07 (no auto-reply) will now observe a non-clean close instead of a clean 1000 close, because the framework no longer fabricates a reciprocation. Clients that pass an explicit close code are unaffected.

partyserver@0.5.4

Patch Changes

• #391 6273c96 Thanks @threepointone! - Persist a __ps_name fallback for name-based Durable Objects during initialization. This lets alarm handlers recover this.name even when firing on a stale on-disk alarm record that was scheduled by an older workerd version that didn't yet persist name into the alarm record. See #390.

• #393 5335251 Thanks @threepointone! - Complete the WebSocket close handshake when a client initiates the close. Previously, both the hibernating webSocketClose handler and the non-hibernating close-event listener forwarded to user onClose but never sent a reciprocal Close frame, leaving clients stuck in CLOSING until they timed out and reported 1006 (abnormal closure). The framework now reciprocates the peer's Close frame in a finally block on both paths — required by the Hibernation API on every compat date, and required by the standard accept() API on compat dates before 2026-04-07 (where the runtime's web_socket_auto_reply_to_close flag isn't yet active). Calling close() on an already-closed socket is a silent no-op, so user code that already calls connection.close(...) from onClose is unaffected. Reserved close codes (1005, 1006, 1015) are normalized to 1000 before reciprocation so they don't throw InvalidAccessError. See #389.