#1091 mod_muc does not handle storage driver connection failure on startup
What steps will reproduce the problem?
1. Connect your Prosody server to a SQL storage backend
2. Set up a MUC room, do some configuration etc
3. Reboot the server, if Prosody comes up before your SQL then bad things happen to your MUC rooms...
What is the expected output?
Everything to be exactly the way I left it at reboot.
What do you see instead?
Whoever connects to the MUCs first generally becomes owner of it, configs are reset etc etc.
What version of the product are you using? On what operating system?
Prosody 10 on Debian 9.
Please provide any additional information below.
N/A, Zash told me to make this issue, so he understands it. :)
Let's limit the scope of this issue to the data loss on startup.
The problem is that on startup, a list of all persistent rooms are loaded. If no data is returned or if there's a storage failure, the list is initialized to an empty list.
Rooms that are not in this list are treated as non-existent, so creating new ones that overwrite them is allowed.
Ideally one would want to retry loading that list, but that looks like a major refactoring. Incidentally, trunk has already had that refactoring, so I think the initial fix in 0.10 will be to abort loading of mod_muc, requiring a reload or restart.
titlemod_muc ignorant of storage driver connection failure