Message reactions persist after the reacting user is deleted

[mossae]

Description:

When a user is deleted, their reactions remain attached to messages in the reactions field of the rocketchat_message collection. This creates ghost reactions where a reaction references a username that no longer exists in the users collection.

Rocket.Chat stores reactions using usernames instead of user IDs, and the user deletion process does not currently remove these references.

As a result, message reaction data may contain usernames belonging to users that have already been deleted.

Steps to reproduce:

1. Create two users (User A and User B).

2. Send a message in any channel or room.

3. React to the message using User A.

4. Delete User A from the workspace.

5. Check the message reactions.

Expected behavior:

When a user is deleted, their username should be removed from all message reactions so that no orphan references remain.

Example expected structure:

reactions: {
":thumbsup:": {
usernames: ["userB"]
}
}

Actual behavior:

The deleted user's username remains in the message reactions.

Example:

reactions: {
":thumbsup:": {
usernames: ["userA", "userB"]
}
}

Even though userA no longer exists in the users collection.

This results in ghost reactions remaining in message data.

Evidence

Reaction before deleting the user

isha.walia reacts to a message and the reaction appears normally.

Reaction after deleting the user

isha.walia has been deleted, but the reaction still appears on the message.

Server Setup Information:

Version of Rocket.Chat Server: 8.3.0

License Type: Community

Number of Users: Not required for reproduction

Operating System: Linux

Deployment Method: Development environment

Number of Running Instances: 1

DB Replicaset Oplog: Enabled

NodeJS Version: 22.16.0

MongoDB Version: 7.2

Client Setup Information

Desktop App or Browser Version: Latest Chrome(145.0.7632.160)

Operating System: Linux

Additional context

Reactions are stored inside the message document using the following structure:

reactions: {
":emoji:": {
usernames: [...]
}
}

Since usernames are stored directly, deleting a user does not automatically remove them from the reaction lists. Cleaning these references during user deletion would prevent orphan reaction entries.

Relevant logs:

The issue results from stale reaction data remaining in the database after user deletion.

[mossae]

I'm working on this and will raise a pr solving this issue shortly!

[adwait50]

Hi, I looked up on this issue and found that -

Root Cause-
The reactions are saved in the message document in a field called reactions with the following format:

{
"reactions": {
"👍": { "usernames": ["userA", "userB"] }
}

Because the usernames (not user IDs) are used, and the deletion user process in deleteUser.ts (apps/meteor/app/lib/server/functions/deleteUser.ts) does not have any step to clean up the reaction references, the username of the deleted user appears in all message documents.

Proposed Fix and approach-
I would include a removeReactionsByUsername(username) to the Messages model (packages/models/src/models/Messages.ts) which I would invoke in deleteUser.ts with the other username-dependent deletions, such as Rooms.updateGroupDMsRemovingUsernamesByUsername.

In the cleanup query, there are two ways we might do it-

1. With a single MongoDB query, which can be written as $pull with arrayFilters -a to pull out the username of all reaction arrays in all messages, then a second query can be run to pull out any emoji keys that will be left with empty arrays of usernames.

2. JS fetch and update - fetch messages with reactions, filter in application code and update all changed documents. Less efficient at scale, but easier to read.

I was inclined to approach 1 on performance, but would like to consult the maintainers before going on with it.

[mossae]

Thanks for the detailed breakdown --this matches what I was exploring as well. Got busy with my GSoC proposal, but I was thinking along similar lines.

Since reactions are stored under dynamic emoji keys, the cleanup needs to handle all nested usernames arrays across variable keys rather than a fixed field path.

I’m planning to:

1> Use a Mongo $pull-based cleanup to remove the username from all reaction arrays
2> Follow it with removal of empty reaction entries
3> Keep this within the deleteUser flow for now

I’ll take this forward and follow up with a PR.

[adwait50]

Sure thing! let me know if you need any help and I would love to review that PR.