What steps will reproduce the problem?
1. module:reload('muc') in the admin_telnet console
What is the expected output? What do you see instead?
I get a "cancel: not-allowed" error back after typing a message in a room on the component I just reloaded.
It would be nice to get some kind of warning in the muc itself that the service is reloading or restarting.
What version of the product are you using? On what operating system?
r8168+.45be94611593+-1 on Archlinux.
I am unable to reproduce this, can you provide a debug log and your configuration?
The issue in the title and the error should probably be splitted.
For the issue in the title, from what we discussed in the prosody room, that is a non-issue, as people should not fall off MUCs when the module is being reloaded, (and I reproduced, workscorrectly).
Now for the "cancel: not-allowed", I tried to reproduce, and the only way I could get it was by restarting prosody.
- Local user on @localhost
- Joins email@example.com
- Room set persistent (not sure if it's important here)
- Restart prosody
- User gets disconnected, reconnects.
- MUC tab still opened in client, shit happens when a message is sent.
I managed to reproduce something similar, however I determined that poezio simply lets you send messages without being joined. This does indeed produce a 'cancel: not-allowed' error from here: https://hg.prosody.im/trunk/file/8648cb171213/plugins/muc/muc.lib.lua#l978
So far, everything seems to be in order. Telling the client to rejoin the room makes everything work again here.
titleTrunk doesn't warn in muc on muc reload
So this is more of an issue of the client not making it obvious that one isn't in the room.