No messages visible after upgrading to 8.4.0 in Docker

What version are you coming from?

Coming from Rocket Chat version 8.0.1 and MongoDB version 8.0.13

What version are you going to?

Going to Rocket Chat version 8.4.0 (or any version after 8.0.1) and MongoDB version 8.2

What deployment method did you use to deploy?

Docker compose

Did you follow a particular doc? Which one?

What issues are you running into upgrading?

I have tried both, changing the version number in my current instance to a later version. Then using ‘docker compose up -d’ to upgrade. And Creating a fresh install using the linked guide, then using ‘docker exec -i <container_name> sh -c ‘mongorestore --archive’ < db.dump’ to restore the data from the old working instance I had backed up before. After which I restart the containers with no success each time.

I had originally setup the Rocketchat container about a year ago using docker compose that had different instructions and only one compose.yml file. Hence why I tried a fresh install of 8.4.0 as it sets up more containers than before.

I have been able to rollback but cannot keep using this old version for much longer.

Start here:

As has been suggested multiple times do NOT jump releases.

So 8.0.x to 8.1.x to 8.2.x etc so you can see when the issue occurs and a better chance of debugging it.

Suggest you restore completely, check it works, then update incrementally.

I have just tried that and version 8.2.0 onwards seems to be the issue.

I upgraded my live instance from 8.0.1 to 8.1.0 fine and got the same issue again when going to 8.2.0, but I could rollback to 8.1.1. I also created a new fresh rocketchat at 8.2.0 using the docker compose instructions you have linked and upon restoring the database I get the same problem.

The only other difference in the new Rocketchat I created is the MongoDB container is at 8.2.0 instead of 8.0.13.

There is no chance of multiple containers using the same ports as I shutdown the live instance before starting up the new one in a different directory and using separate Docker volumes.

What should I try from here? I have checked the docker logs when starting the problematic version of Rocketchat but I don’t really see any obvious errors unless there are key indicators I should look out for?

You CANNOT mix n match mongo versions.

Restore to the same version, and upgrade - don’t ever restore to a different version - there are lots of docs on upgrading Mongo.

And downgrades are pretty suicidal (read more here) due to db updates that Rocket often makes.

Better to incrementally upgrade JUST Mongo, test, upgrade JUST Rocket, test etc.

Scattergun approach & guess work will just toast stuff.

You can grab a Mongo gui app to read your db & check for the presence of messages and make sure they are there.

I have the same issue. Upgraded to 8.4 and no messages are visible. If i start a chat I can see it, but if I close out of the application and re-open it, the conversation disappears.

Addtionally, in the top left where the server is listed, it says “Not Logged In”, even though I can see all the information in the workspace and the users. Quite confusing.

Have you all updated to 8.4.1 ?

Hello I have followed your advice and did a complete restore to a fresh install of Rocketchat compose containers to the same version of Rocketchat and MongoDB that was running on my live instance and when I upgraded from 8.1.1 to 8.2.0 I got the same issue. Same as @tpmurdock is having.

Can you advise your licence type & number of users.

Have you checked your logs??

Put them in debug mode and then check. The answer is likely in there.

Seems similar to an earlier issue: Empty Chats after Update to 8.2.0

I’m still on 8.1.1, as all messages remain visible in this version.

Any chance everyone with disappearing messages is using HTTP and not HTTPS? Could be related this this bug report on Github: Messages are stored and searchable, but message list becomes empty after refresh in channels and DMs · Issue #40152 · RocketChat/Rocket.Chat · GitHub

I have not successfully transitioned to HTTPS to confirm that this matter has been resolved. As a Docker-only user, enabling debug mode and delving into logs isn’t as easy as it may seem.

I have only ever had mine configured with HTTP.

You absolutely should NEVER use http.

Rocket is NOT a webserver.

It serves html via node over port 3000 but that is NOT the same thing.

For your own security you should ALWAYS have a https reverse proxy in front of it.

It should be accessible ONLY via ONE host.domain - if not the host setting can get modified by users and that can break your server.

See Step 5 here:

Once your Rocket.Chat instance is deployed, you can access the workspace through your web browser to begin your final configuration:

  • For local deployment: Go to http://localhost:3000.

  • For production: Navigate to the domain you configured

Local deployment means on your own workstation for development testing ONLY. Any other use is unsupported.

For production you should be using a domain and reverse proxy with https. If you don’t then things may break. (and a domain costs peanuts and https certs from letsencrypt are free so zero excuses there)

So update your setup now and then check what works.

You can set the Rocket log level in the admin/Log setting

docker logs are pretty easy - if you use docker then just read the docs (and the docker docs). All the work has been done for you already…

Every chance. As per my previous message above, Rocket shoudl NEVER be accessed over http unless you are developing on your own machine.

Fix it now.

Hi we are only hosting Rocketchat locally on an internal network. I understand the importance of HTTPS but we do not have certificate system setup for that. I am still under the assumption that this is a database issue however.

The answer will be in your logs.

But you have been less than forthcoming with information, which makes it very difficult to help.

You do know you that there are restrictions on airgapped usage?

As far as https goes you can generate a self signed cert easily.

But as we know nothing about your setup we can’t say much else.