Bug: in-conversation notification suppression matches on group id alone, silently dropping a notification for the same MLS group under a different local identity

[erskingardner]

Severity

LOW (multi-account, same-group edge case — a missed notification, not a leak)

Summary

handleNotificationUpdate is a client-wide listener that fires for every local account. Its "don't notify me about the chat I'm already looking at" suppression checks only selectedChat?.id == update.groupIdHex (plus visibility) and never checks that update.accountIdHex belongs to the currently active account. selectedChat is always the active account's selection, while update can target any local identity. MLS group ids are globally unique, so if two of the user's local identities are both members of the same group, they share a groupIdHex.

Location / Evidence

whitenoise-mac/Core/WorkspaceState+Notifications.swift:48-50

if selectedChat?.id == update.groupIdHex, selectedConversationIsVisible() {
    return          // no check that update.accountIdHex == active account
}

Contrast: the settings-sync block just above (:37-44) does gate on the active account via ownsNotificationSettingsOperation(...); the suppression does not.

Failure scenario

1. User has identities A and B, both members of group G (same groupIdHex).
2. User is viewing G under account A (selectedChat.id == G, visible).
3. A message arrives addressed to B in G. handleNotificationUpdate for B evaluates selectedChat?.id == update.groupIdHex → true, conversation visible → the notification for B is suppressed.
4. The user is not actually reading B's copy of the conversation and receives no alert for B's message.

Why this is not a duplicate

• Bug: tapping a notification whose account was removed (or otherwise unresolvable) selects the group under the *currently active* account with no ownership check #256 / Tapping a notification for a non-active account switches accounts without the normal teardown (stale peer-profile cache + stale observability account label) #99 concern notification tap handling and account ownership on selection, not the delivery-suppression predicate.
• Bug: handleNotificationUpdate syncs the published notificationSettings snapshot without the notificationSettingsGeneration guard (gap in the #228 fix), letting a stale FFI read clobber a just-committed toggle #428 / Bug: loadNotificationSettings()/setLocalNotificationsEnabled() write account-scoped settings after an FFI await with no stale-account guard #228 concern the settings-snapshot generation guard, not the group-id match.
• Bug/Privacy: tapping a notification for a same-account chat bypasses leaveActiveConversation() — mic stays hot and the voice recording is misfiled to the new chat #374 concerns mic teardown on notification tap.

Suggested fix

Gate the suppression on the active account as well:

if activeAccount?.accountIdHex == update.accountIdHex,
   selectedChat?.id == update.groupIdHex,
   selectedConversationIsVisible() {
    return
}

Found during a full-codebase review.