243bd04d9749362b603bd811b18dc7c82a26e04b
Reported from the mac: the alpha pane opened and read fine, and sending produced nothing at all. The console showed the socket closing before it was established. send dropped the message — readyState !== OPEN returned, silently, no error and no retry — so enter did nothing and no turn ever started. Alpha was never at fault: the same key opens that socket from outside the browser on the first try. The window is not rare. React dev StrictMode double-invokes effects, so every socket is created, closed and recreated on mount, and a reconnect reopens it again; with three chat panes there are three sockets doing it at once, and one is always briefly not OPEN. One pane with one stable socket is why this never bit before. Queued and flushed on open, in order, after the resume/attach handshake rather than in front of it. Bounded at 50 so a socket that never returns cannot grow it without limit, oldest dropped first because the newest message is the one being waited on. The mobile chat app has had this queue all along, for this exact reason. I read it this morning, wrote the reason down, and did not port it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
No description provided
42 MiB
Languages
TypeScript
90.9%
Shell
4.7%
JavaScript
4.1%
CSS
0.2%
HTML
0.1%