Broadly, this is messy because:

• We can't solve this completely by immediately marking the notifications as read or not generating it: the object may become invisible to the user between the time we generate the notification and the time they view it.
• It's desirable to generate notification counts cheaply, without needing to policy filter everything.

Possibly this leads to "don't generate" + "when the user looks at their notifications in detail (vs just the count), mark all the ones they can't see as read" sort of fix. This is a little sneaky since you click "3" or whatever and then they vanish, but better than having relatively un-clearable notifications. I suppose we could tell you "3 notifications about things you can no longer see were dismissed" to make this a bit less magical.

I suppose we could tell you "3 notifications about things you can no longer see were dismissed" to make this a bit less magical.

wfm

Yeah, I don't think it's terrible since it should happen very rarely if we do "don't generate" too, and no matter how clever we are it's unavoidable in some cases (even if we policy filter, we might send down a "3", and then by the time the user actually opens the menu or clicks the bell they can no longer see one of them).

Until the root cause is fixed, can we at least have "Mark all as read" get rid of them?

Otherwise how do I fix this? What I ask the owner of the task I don't have access to unsubscribe me, will it get rid of them?

"Mark All Read" should remove them, but only if you have another newer notification than any of the phantom notifications.

It does indeed, thanks!

See also T4411, although I expect to get to this before that.

After D19384, we'll automatically mark these "phantom" notifications as read when you open the menu to review them:

T13131 has some followup discussion, but the changes it considers address more obscure and less annoying behaviors than this.