Closed wtomaszewski-applause closed 1 year ago
When you send presence unavailable, you also trigger leaving muc room (muc uses presence to track which users are in room, when it receives presence unavailable user is removed from a list). This will stop muc from sending message to you - you are no longer room member (this explain why there no muc messages in offline storage). Sending presence after reconnect will also not join room for you, it will send presence to entries in your roster, and i guess your room is not in that list, this is why you need to explicitly trigger room join.
There is https://docs.ejabberd.im/developer/xmpp-clients-bots/extensions/muc-sub/ that allow you to make muc send you notifications about messages without using presence based tracking.
I appreciate you providing the background on why that problem is occurring. Just to be sure, if I want to use the muc-sub extension, do I need to use it for all of my private, groupchat, and customized notifications as well? Mod client state must be replaced with the muc sub extension? In my solution, I have a logic that runs "unavailable" when a user enters background mode in a mobile application, so that it applies to various notification types in addition to "groupchat" messages.
With using the mucsub extension and the suggested method, I was able to resolve that issue. For groupchat message types, I used mucsub to send a subscribe iq stanza to the chat room instead of joining the chat room using MUC join which sends an "available" presence. Then, as I switch to the unavailable mode, I send an mucsub iq stanza to unsubscribe. After switching back to the available state and subscribing again, I started getting the queued messages instantly.
Thank you very much for your quick help in solving the problem, seems the mod_client_state
requires mucsub
iq subscriptions instead of presence stanzas for groupchat messages.
One observation, when I enabled allow_subscription: true
for mod_muc
in ejabberd config, the modmuc subscription for existing chat rooms returns Subscriptions are not allowed
error. But when I created new chatroom that subscriptions were working. Not sure if that is configuration issue, maybe I'm missing some config which allows subscription for existing chatrooms.
Environment
Configuration (only if needed):
Errors from error.log/crash.log
No errors
Bug description
I would like to use
mod_client_state
module from ejabberd to disable all websocket message handlers when user is in background mode and enable when user is going back toavailable
mode. I'm using https://github.com/strophe/strophejs library for which I'm using MUC plugin to sendjoin
presence to specific chat room. I have client implementation to receivegroupchat
andchat
(private) messages:That code is working and I'm able to receive all new messages in real time by above handlers. I used
mod_client_state
and I go tounavailable
mode than messages are not received for both handlers which is expected and desired here. But when I go toavailable
mode, then the first handler for private messages receives queued messages immediately but the second handler forgroupchat
stops working and I need to executejoin
function from MUC plugin again but it seems that handler is not longer receiving any groupchat messages.It seems that only
groupchat
messages are not working withmod_client_state
plugin because forchat
or custom messages I'm able to receive queued messages in handlers. I did a look and forgroupchat
messages when user in unavailable, the messages are not stored inspool
table but private messages are stored in that table.Below I'm sending message example. If the user uses
mod_client_state
then forgroupchat
messages, that user will not be visible in destinations list until user will reconnect websocket connection which is something which I want to avoid.Overall I would like to report two bugs here:
unavailable
andavailable
presence with CSI xmlns, then user jid is not longer visible inDestinations
list.groupchat
type are not stored inspool
table.