Some users have duplicated self-DM (direct message) rooms

Community Support
1

Description

Disclaimer: I have a long-lived Rocket.Chat setup that has been migrated through multiple major versions over the years, and I think this issue might be related with that. Also, if this has already been asked, please just say so, I tried looking but didn’t really find anything matching.

The visible effect for my issue is that users self-DMs (direct messages to themselves) just disappear. I often use this feature as a notepad of sorts, writing messages for myself about things I want to check out later etc. That DM history I’ve built up over the years just disappeared one day.

Debugging I’ve Done Thus Far

I looked up the chat rooms on the admin UI and found that there are two rooms for those private messages. Checking the JSON response or the rooms request in dev tools, I could also see a few differences in them:

  • One named “(my-username) x (my-username)”
    • Appears to hold all my message
    • Room is old, as old as the installation
    • The room ID is actually (my-user-id)(my-user-id)
    • Contains my own user twice
  • Second one named “(myusername)”
    • Room is new, created on the day my issue appeared
    • No old messages
    • The room ID appears to be random
    • Contains my own user only once

If I go the DM room and swap the ID in the URL, I can see and use my old self-DM-room normally. It’s easy enough to just take that back into use I guess, so I’m not terribly worried.

However, I found that my other users also have a varying degrees of the same issue, which implies that my database might not be quite in the shape it should. I think the break-off point is somewhere in 2022 - people that started using self-DMs before that had the (username) x (username) rooms and after that the form has been the plain (username). Early 2024 is the first instance of a user getting the double-rooms situation. Not sure what triggers them to sometimes get the latter room created even though they already have the former. I tried searching the github issues and didn’t really find anything related.

The Question: Would it be safe just move all the messages in mongo?

So I was thinking maybe I should just migrate all the messages from the old-form rooms into the new ones in mongo and then wipe out the old rooms. I’m not too familiar with the rocket database structure, so I wanted to ask if someone had some insight. Would this be a bad idea? Is there something that could break? Are there some references that would need to be fixed?

Also, if the latter form is how the self-dm rooms should be, then maybe some migration in my DB history didn’t quite go as planned? Any idea what the structure change might be about or something I could check further?

Server Setup Information

  • Version of Rocket.Chat Server: 7.10.0
  • Operating System: Debian 11
  • Deployment Method: Docker
  • Number of Running Instances: 1
  • DB Replicaset Oplog: Enabled
  • NodeJS Version: v22.16.0
  • MongoDB Version: 7.0.23 / wiredTiger
  • Proxy: Nginx (SWAG)
  • Firewalls involved: Server firewalld + router NAT

Any additional Information

2

Almost certainly an old self-inflicted wound.

Why not just create yourself a private channel with you as the only member?

Eg:

#FredsOwnPrivateNotepad`

Not sure there is a simple solution.

Yup, you can possibly hack the DB, but always risky and nothing I can suggest there. Backup first….

Can you access the old DM via the API, read the messages, and post back in order to your new channel?

The API will be much safer.

3

Something similar happened to me. I also used a direct message channel with myself for years just for note taking or to test formatting of my messages.

Today, I see two channels with myself. One of them is the channel I’m using for a long time. The new one is just empty. I can send messages to both channels. They seem to be completely independent from each other. So it’s basically the same issue except I can still see the old channel.

In the Admin UI, it looks exactly the same as @bozzib described.

We also have a long-lived instance.