partysocket@1.2.0
·
10 commits
to main
since this release
Minor Changes
-
#403
7e042ebThanks @threepointone! - Make buffered messages and connection teardown reliable across socket replacement and explicit close (see cloudflare/agents#1738).close()now dispatches itscloseevent synchronously (mirroring howreconnect()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. Afterclose()returns,readyStatereportsCLOSEDimmediately, even while the underlying socket finishes its closing handshake. Code that attached acloselistener after callingclose()and relied on the event arriving asynchronously must attach the listener first.send()now returns aboolean:trueif the message was transmitted immediately over an open connection,falseif it was buffered (delivered when the connection next opens, always before theopenevent is dispatched) or dropped becausemaxEnqueuedMessageswas 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 bysend()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. onlyquery— 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 newtransferEnqueuedMessagesoption overrides this:truealways transfers,falsenever does. - Warn when
send()is called afterclose(). Messages sent against a permanently closed socket are buffered into a queue that nothing will ever flush (unlessreconnect()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 onreconnect().