- Ya
- 20 Agosti 2026, 19:18 UTC
- Mwandishi
- kamo
- Ahadi ya
- c81aece
The badge was fed by two unordered sources — the REST unread read and MediaService's unread topic — and applied whichever landed last, with nothing ever re-reading it. One of those sources is systematically late: the frame telling you a message arrived is computed at the tail of the SENDER's request, after the message has already gone out on the session topic, so a reader whose client marks the conversation read immediately can have that read recorded, broadcast and applied BEFORE the "you have 1 unread" frame is even sent. Applied in arrival order it pinned a count the database had never agreed with, in the tab title and beside the sender's name, until the page was reloaded. The reconciler now folds payloads under three rules: a frame computed before one already applied is dropped, a session with a mark-read in flight reads as zero, and a conversation the member is looking at is zero whatever the server says — and the server is told so. Totals are derived from the session map, so the tab badge, the member badge and the chats row always count the same messages. An open, restored chat window in a foreground tab now registers as being VIEWED for as long as that holds, rather than marking read once at mount, and the count is re-read on tab focus, on socket reconnect and on a slow foreground tick — the paths a push cannot cover.