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.
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?
1 Like
Moin
June 13, 2024, 9:37pm
4
I was able to reproduce the issue.
Clicking Dismiss removed the notification
1 Like
sam
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
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
Users were seeing a notification badge count that didn't match what was actually… shown in the notification list - the classic "stuck notification count" bug.
## Root Causes
This was caused by three separate issues:
1. **Hard-deleted topics**: The `visible` scope SQL had a logic error. When checking for deleted topics via LEFT JOIN, the condition `topics.id IS NULL OR topics.deleted_at IS NULL` incorrectly included notifications for hard-deleted topics (where topics.id becomes NULL after the join).
2. **Inaccessible topics**: Count methods in the User model used raw SQL that only checked `deleted_at`, completely ignoring category permissions and PM access. Users who lost access to a private category or were removed from a PM still had those notifications counted.
3. **Scattered logic**: Notification visibility logic was scattered across 7+ methods with inconsistent filtering, making count vs. display mismatches inevitable.
## Solution
Introduces `NotificationQuery`, a centralized class that handles all notification visibility at the SQL level. This follows the same pattern as `BookmarkQuery` and ensures counts always match displayed notifications by filtering for:
- Hard-deleted topics (topic no longer exists)
- Soft-deleted topics (staff can still see these)
- Category permissions (user must have access)
- PM access (user must be allowed on the topic)
- Disabled badges (badge notifications for disabled badges are hidden)
## Changes
**New files:**
- `lib/notification_query.rb` - Centralized query class
- `spec/lib/notification_query_spec.rb` - Comprehensive tests
**Modified:**
- `app/models/user.rb` - Delegate count methods to NotificationQuery
- `app/models/notification.rb` - Remove scattered visibility logic
- `app/controllers/notifications_controller.rb` - Use NotificationQuery
- `app/controllers/users_controller.rb` - Use NotificationQuery for user menu messages
- `app/serializers/user_notification_total_serializer.rb` - Simplify query
- `lib/bookmark_query.rb` - Use NotificationQuery for bookmark reminder notifications
---
Redo of #27589.
Ref - t/121464
