Live updates reach your other tabs again
- fixed When you rename yourself in a chat, every other tab and window showing that conversation is supposed to pick the new name up within a second. On the deployed app that live channel was being turned away at the door: the page asked for it without identifying itself, so the server answered "not logged in" and the browser kept quietly retrying. The channel now identifies itself properly, and renames (and future live updates) arrive everywhere they should.
Chats update live in more than one way. Messages arrive over the chat connection, but small application events, like renaming yourself in a conversation, travel on a second, quieter channel that the page keeps open in the background. That's how a rename you make in one tab shows up in your other tabs, and in the sender's view, about a second later.
On the deployed app, that channel was being refused. The deployed interface and its server live on different addresses, and a background channel like this only carries your login cookie across addresses if the page explicitly asks it to. It didn't, so the server saw an anonymous request and answered "not logged in", and the browser settled into quietly retrying forever. Nothing you saw broke outright: messages still flowed, and names still updated when you reopened a chat. What you lost was the live part, plus a stream of "can't establish a connection" notices in the browser console if you had it open.
The channel now asks for the cookie properly. Renames reach every open tab and the sender's window within a second, the same as they always did in local development (where the two addresses are one, which is exactly why this never showed up before shipping).
← All changes