Priority/Severity : low
Platform : Windows/Android
Description : On Windows and on Android, I’m seeing an unread personal message notification, but when I click on it, it says the page doesn’t exist or is private.
There seems to be no way for me to clear the notification since I can’t read the message.
Reproducible steps : I haven’t tried to reproduce it, but what happened was I was removed as a recipient while the message was unread, so I no longer have permission to view the message.
2 Likes
Moin
June 13, 2024, 9:22pm
2
Does the number disappear when you reload the site?
That’s what I did to get rid of the notification for a like when someone has liked one of my posts and deleted it immediately afterwards.
1 Like
Moin
June 13, 2024, 9:37pm
4
I was able to reproduce the issue.
Clicking Dismiss removed the notification
1 Like
sam
(Sam Saffron)
June 14, 2024, 3:51am
5
If you can not dismiss it from the top, maybe try dismissing it from your profile, notification tab (there is a dismiss all) ?
I guess there are 2 questions here
How did the bug happen (my guess, maybe being kicked out of a PM can trigger this)?
How to get this annoying notification to go away (hopefully the dismiss stuff helps)
2 Likes
Moin
June 14, 2024, 6:04am
6
I followed the steps from the first post
Send a message to a user
Remove the user from the message
Log in as this user
Get rid of the notification by dismissing all notifications
2 Likes
Moin
August 29, 2025, 4:29pm
7
This still happens, and it is still difficult to get rid of the notification. In particular, you cannot dismiss the single notification, so you first have to check all the other notifications caused by messages.
To some extent, this is even a security vulnerability, as the user should no longer have access to the title of the message.
2 Likes
sam
(Sam Saffron)
August 31, 2025, 11:43pm
8
I put a note for the team to triage in the next few weeks.
2 Likes
Moin
December 8, 2025, 5:23pm
10
Is there any news on this?
I still find it concerning that users I remove from a PM can still see title changes. This affects my ability to rename a topic that I convert into a personal message. There is a reason why I remove the user, and I don’t want them to have access to the new title.
2 Likes
I’ll see if i can reproduce
2 Likes
We were indeed missing some “cleanup” path when removing users from PMs (either directly or through a group).
main ← fix-phantom-notification-after-being-removed-from-a-pm
closed 03:07PM - 13 Feb 26 UTC
Users were experiencing "phantom notifications" - seeing an unread notification … count but being unable to find or dismiss the notifications. This happened because notification counts don't verify PM access, while the notification list filters out inaccessible ones.
The root cause was that notifications weren't being deleted when users lost PM access through various paths: being removed directly, having their group removed, or being removed from a group.
This fix:
- Adds `Notification.orphaned_pm_notifications` scope to identify notifications for PMs the user can no longer access
- Calls cleanup from `Topic#remove_allowed_user`, `Topic#remove_allowed_group`, `Group#remove`, and `Group#bulk_remove`
- Adds cleanup to `Notification.ensure_consistency!` as a safety net
- Includes a migration to clean up existing orphaned notifications
Report - meta/t/311995
2 Likes
Moin
December 9, 2025, 11:19am
14
Moin
January 12, 2026, 8:41pm
15
This has been open for a while now. Is there anything else needed for this, or has there simply been no time to review and merge it so far?
I have been working on fixing the root cause of several related inconsistencies regarding notification counts so my above PR has been superseded by this one
main ← fix/stuck-notification-count
approved 05:24PM - 06 Feb 26 UTC
Notification badge counts could get "stuck" — showing a number higher
than the a… ctual visible notifications. This happened because count
queries used lightweight SQL (only filtering deleted topics), while
display queries applied full access control via Guardian. When a user
lost access to a topic — removed from a group/PM, or category
permissions changed — the notification persisted in counts but was
filtered from the displayed list.
Additionally, the `visible` scope had a logic error: the LEFT JOIN
condition `topics.id IS NULL OR topics.deleted_at IS NULL` incorrectly
included notifications for hard-deleted topics.
The fix introduces `NotificationQuery` (following the `BookmarkQuery`
pattern) — a centralized class that handles all notification filtering
at the SQL level, ensuring counts always match displayed notifications.
Access control uses a CASE on topic archetype: PMs check
topic_allowed_users + topic_allowed_groups; regular topics check
category read_restricted against the user's secure_category_ids. Shared
drafts are excluded when the user lacks access. Admins without
suppress_secured_categories_from_admin skip all checks. Badge
notifications are handled via Ruby post-processing when enable_badges
is false.
To prevent DB bloat from orphaned notifications, model callbacks
enqueue DeleteInaccessibleNotifications when access is revoked:
- TopicAllowedUser after_destroy — enqueues with topic_id
- TopicAllowedGroup after_destroy — enqueues with topic_id
- GroupUser after_destroy — enqueues with user_id + group_id
- Category after_update — enqueues with category_id when permissions change
The job supports three modes: topic_id (checks each user via Guardian),
category_id (iterates topics, delegates to topic_id mode), and
user_id + group_id (finds affected topics, bulk-deletes where user
lost access).
Redo of #27589.
Ref - t/121464
1 Like