#1091 mod_muc does not handle storage driver connection failure on startup

Reporter Kane Valentine
Owner Zash
Stars ★ (1)  
  • Type-Defect
  • Priority-High
  • Status-Fixed
  • Milestone-0.10
  1. Kane Valentine on

    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. :)

  2. Zash on

    • tags Status-Accepted Milestone-0.10
  3. Zash on

    • tags Priority-High
  4. Zash on

    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.

    • tags Status-Started
    • owner Zash
    • title mod_muc ignorant of storage driver connection failure mod_muc does not handle storage driver connection failure on startup
  5. Zash on

    Abort module load: https://hg.prosody.im/0.10/rev/7e7aa0f770c7 Lock individual rooms that can't be loaded: https://hg.prosody.im/0.10/rev/416b8ae3857d Testing these would be appreciated.

    • tags Status-Fixed

New comment