- Shipped
- 14 Agosti 2026, 23:24 UTC
- Author
- kamo
- Commit
- e3ee830
The nav-top bell was live for arrivals and nothing else. Reads, dismissals, snoozes and deletions were applied to whichever tab the member clicked in and announced to nobody, so clearing the centre in one window left every other one — and their phone — counting notifications that no longer existed, with no path back to the truth short of a reload. EmailService now publishes every change of state on the same per-member topic it already publishes arrivals on, and the browser applies all of them idempotently: the tab that caused a change receives its own echo like everybody else, so each transition has to be a no-op the second time it lands. Three fixes fall out of that: - Quiet hours and do-not-disturb held the whole notification, not just the toast. The badge stayed frozen for the length of the window, which made the member who had configured the feature the only one whose count could not be trusted. A held notification is now published `silent`: it counts, it just does not interrupt. - The unread count is moved through a ref-backed ledger rather than four copies of "and take one off the badge". Every action is now applied twice by design, and two copies of that arithmetic is exactly how the second application subtracts something the first already did. The server's total still seeds it, so a member with more unread than the centre holds still sees the true number. - A socket that has been away — a sleeping laptop, a redeployed pod — refetches on reconnect, and the pile the server hands over on connect can now re-toast a notification the history load has already listed. That pile was being discarded as duplicates, so a member who was offline came back to cards they were never shown. The wire contract lives in a pure `readNotificationEvent` with a test that spells out each `type` string, because a drift on either side does not fail loudly — it falls through to "an arrival" and puts a dismissal back on screen as a toast.