- Ya
- 14 Agosti 2026, 02:09 UTC
- Mwandishi
- kamo
- Ahadi ya
- a29e9fa
Reading a conversation updated the server and then waited for the news to come back: PUT /read commits, MediaService broadcasts a fresh count over core NATS, the relay puts it on a STOMP topic, the browser applies it, and only then does the ticket list refetch and drop its marker. Every link in that chain works — I checked the relay is subscribed and the broadcasts are going out — but the member's own action should never have depended on it. Until it completed, or until they reloaded, the marker they had just cleared was still sitting there. The window now announces the read directly, and both surfaces listen: the ticket list clears that row's marks, and the badge re-reads its count. The push still arrives and still reconciles — this only removes the latency, and the server stays the authority on the number. Announced after the two writes settle, not before. Announcing first would let the badge's re-read race the very writes it is reading and come back with the old number, which is the same bug one layer down. A write that fails announces nothing, so the marker stays — correctly, because nothing was read. The list's marker also keys on ticket id now rather than session guid, since that is what a read is announced with, and it clears both marks: reading a conversation genuinely retires its handover as well as its unread messages.