- Shipped
- August 27, 2026 at 1:07 AM UTC
- Author
- kamo
- Commit
- a9ba632
senderId is what pins an unread badge to a person — their member-directory row, their hex head — so it has to mean "these messages are from them". It was set for every session with anything unread in it, to whichever participant came back first from an unordered membership read. That is the reported bug. A member with three open support tickets had all three attributed to the org member the tickets named, so their directory row read "6 unread messages" — six messages the direct chat with that member did not contain and opening it could not clear, because they were in three other conversations, which live on the support surface and already have a badge there. The rule moves to UnreadSenderAttribution, beside OwnAuthorshipAmbiguity and for the same reason: it decides whether a badge appears at all, so it should be stated once and tested. It has one case — a two-party CHAT, where the count already excludes the viewer's own messages, so every message left in it is the other participant's. A support ticket, a social thread and a group chat all name nobody; a group because more than one other participant means naming one is a guess.