Restore your backup. You can’t do these huge version jumps and expect it to work.
Before starting again I’d make sure you have stopped using GridFS and all your files/images are in local storage.
You need to migrate mongo one version at a time. 5 → 6 → 7-> 8
Check each works.
(You should have been on Mongo 7.x a long time ago)
Check the Mongo “featurecompatibility” setting mentioned multiple times.
Then finally upgrade Rocket, and personally, as per their docs, I’d do it a version at a time eg 7.11.x → 7.12.x etc as their upgrade Q&A is pants.
Unfortunately, I cannot restore the backup without losing six hours’ worth of messages. The issue unfortunately went unnoticed during testing, and everything else works flawlessly.
The MongoDB upgrade was performed using dump/restore, which completed successfully. Therefore, it should hopfully not be related to this process.
Regrettably, I trusted the guideline stating that only major releases must not be skipped. Is there a way to run the migration scripts for the minor versions afterward? Alternatively, would it be advisable or even possible, without restoring a backup, to downgrade to version 7.11.4 and then sequentially upgrade through each minor version?
Most likely it is to do with Mongo somewhere - that’s where all your info is stored…
I think you missed this… (I wrote quite a bit of it years ago)
Avoid skipping versions
Not as far as I know - they should run each update but the Q&A is pants and I would not trust them to all run correctly over such huge changes., as per the above migration strategy.
Absolutely not. You will likely compound your problems - you can’t safely downgrade at all due to the way Rocket modifies the DB.
As I said originally, restore from backup and incremental upgrades and full testing is the correct way to avoid issues.
It’s been standard practice for as long as I have used Rocket - about v0.16 IIRC…
Sorry, I missed this part. I just looked at the example, which only lists the major versions.
Since this appears to be the only issue, I will attempt to fix it directly in MongoDB and hope that no further errors arise. Going forward, I will always upgrade through each version sequentially.
Quick update for everyone facing the same problem. The following process updates all messages with an attachment, where the attachment has a description, but the messagebody itself is empty.
Check if you are getting a result with following command
Run this command for a specific message, knowing there should be a description for the image, to test if everything works like attempted.
Replace the _id in the command .
You can find the id with the browser-devtools (see image below)