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.
Zash
on
I am unable to reproduce this, can you provide a debug log and your configuration?
Changes
owner Zash
tags Status-NeedInfo Milestone-0.11
pep.
on
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 foo@muc.localhost
- 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.
Zash
on
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.
Changes
titleTrunk doesn't warn in muc on muc reload MUC not-allowed error after restart
Zash
on
So this is more of an issue of the client not making it obvious that one isn't in the room.
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?
ChangesThe 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 foo@muc.localhost - 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.
ChangesTrunk doesn't warn in muc on muc reloadMUC not-allowed error after restartSo this is more of an issue of the client not making it obvious that one isn't in the room.
Changes