pastilhasandClaude Opus 5
9d2da49572
Three commits backed out a few hours ago as collateral, restored together because they are one fix:243bd04(queue sends until OPEN),bc13450(defer the teardown close by a tick, cancellable) and66a41d0(count CONNECTING as ours, not only OPEN). Why they are needed, from evidence rather than reasoning.d9857eefixed the server side and Andre still had nothing on https://macbook.pastilhas.dev after a restart. The decisive observation is an ABSENCE: his attempts appear nowhere in officer's log — no "Model selected for chat", no claude:stream for his session. Nothing reaches the server at all. Meanwhile a socket I drove by hand against the same wss:// url ran a full turn in 2.5s, so the transport is not it. That is `send` dropping the message. It returned silently on `readyState !== OPEN`, and the socket is not OPEN because the effect cleanup closed it on a remount while it was still CONNECTING, then closed its replacement the same way. Enter does nothing, forever, with the view sitting on Disconnected — and no error anywhere, on either side, which is why this reads as a dead server. Note what is still NOT fixed, and is written into the code comment rather than this message alone: a /chat/new load opens TWO sockets, from two separate useChat instances mounting. Measured with a constructor counter. Both connect, so it looks healthy;d9857eeis what makes it harmless. Correction to d9857ee's message, so the record is not wrong: it claims the localhost/domain split is latency changing the attach/close ordering. That is plausible and it is NOT what was demonstrated — the server-side fix alone did not help. It is still worth having (a stale close silencing a live client is real, and so is the idle GC gate), but the asymmetry is unexplained and the client drop above is what actually stopped a message. Client bundle changes, so this needs a hard reload as well as a restart. Not verified in a browser. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>