- Shipped
- August 21, 2026 at 5:03 AM UTC
- Author
- kamo
- Commit
- c97dd05
Two gaps left over from giving the support window this treatment. Sending a message cleared nothing. The chat core marks a conversation read when it starts, when its history loads and when a message ARRIVES — but not when the member sends one, so replying to somebody left the count exactly where it was. That is the least ambiguous evidence a conversation has been read that the app has, and it was the one signal nothing was listening to. Now marked read on send, ungated: "am I looking at this" is worth asking about a message that arrived and not about one the member just typed. An incoming message in a conversation the member is reading now marks it read rather than merely re-reading the count. Both paths go through the unread context instead of the core's own markRead(), which is the substance of the fix: the core issues a bare PUT, so nothing cleared the badge locally, nothing raised the in-flight fence, and nothing re-read afterwards — the number on screen only moved when the server's broadcast found its way back over STOMP. A refresh() issued against a server that has not recorded the read yet can only ever come back with the count from before it. That is the same round trip the support window stopped depending on: a member's own action should not travel through NATS and a relay before their own screen agrees with them, and when that frame is missed — socket reconnecting, tab asleep — the count sat lit until the next foreground tick or a reload. The handlers read `viewing` and the session through refs. They are registered once per conversation, and `viewing` changes on every minimize, restore and tab switch, so a handler closing over its mount-time value would answer for a window the member stopped looking at long ago.