Gajim ignores not-acceptable errors from MUCs
From https://xmpp.org/extensions/xep-0045.html#message
If the sender is not an occupant of the room, the service SHOULD return a
<not-acceptable/>
error to the sender
Versions
- OS: debian bullseye
- Gajim version: 1.7.0 (flatpak)
Steps to reproduce the problem
- Send a message in a MUC
- Receive an error stanza from the MUC (that should be interpreted as 'gajim is not a participant')
Expected behavior
Gajim should consider that it is not joined to the MUC, and either attempt to reconnect or at least display an error, ideally offering to reconnect.
Actual behavior
The error stanza has not effect on gajim UI: the message is not reflected, which is a hint that something went wrong, but the only workaround is to close/reopen the MUC.
From the gajim XML console:
<!-- Outgoing mer. 22 févr. 2023 11:05:51 (test@localhost) -->
<message xmlns="jabber:client" to="prout-1@dummy.localhost" type="groupchat" id="a1026e5d-616f-4471-aa5c-8b8fd76ded74">
<body>f</body>
<origin-id xmlns="urn:xmpp:sid:0" id="a1026e5d-616f-4471-aa5c-8b8fd76ded74" />
<active xmlns="http://jabber.org/protocol/chatstates" />
<markable xmlns="urn:xmpp:chat-markers:0" />
</message>
<!-- Incoming mer. 22 févr. 2023 11:05:51 (test@localhost) -->
<message xmlns="jabber:client" xml:lang="en" to="test@localhost/gajim.EF51PE8Y" from="prout-1@dummy.localhost" type="error" id="a1026e5d-616f-4471-aa5c-8b8fd76ded74">
<error type="modify">
<not-acceptable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" />
<text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">You are not connected to this chat</text>
</error>
<stanza-id by="test@localhost" id="XwsqJxx7yw0YJKdUHumrCKef" xmlns="urn:xmpp:sid:0" />
</message>
(but nothing in the GUI)
Additional context
This can happen when a MUC service goes down without notifying connected clients via "kick-like presences". While this should not happen in theory, connectivity/hardware failures may happen. FWIW, yes slidge does that sometimes (it shouldn't but well, stuff happens), but I believe I already saw this happen with 'regular MUCs' in the past. I noticed because no activity/messages I tried to send were not echoed.
MUC self-ping (python-nbxmpp#133) is another way to detect MUC services that went down, by regularly pinging the MUC, but I think both could be used in parallel.