Lobby room: Random error in opening it on the server side

Hi,
we enable the lobby when the room is opened on the server side with the relative hook:

host_module: hook (‘muc-set-affiliation’, function (event)
if jid_split (event.jid) ~ = ‘focus’ and event.affiliation == ‘owner’ then
handle_create_lobby (event);
end
end);

inserted in mod_muc_lobby_rooms.lua

I have noticed that sometimes this system fails giving me this error in console:

2022-02-25T15: 27: 01.508Z [modules / xmpp / Lobby.js] Failed joining lobby Error: Missing lobbyRoomJid, cannot join lobby room.

This creates so many problems for me because whoever opens the room is waiting for someone to arrive but no one will ever arrive since they are in a bubble. He will not notice this …

Has this happened to anyone?

can you help me?

When this is happening, is the lobby shown enabled for the user opening the room ?
Do you have any other change done to Jitsi-meet ?

yes, among the security options I see the lobby enabled, but in reality the participants don’t come knocking and the moderator doesn’t see the requests. after an F5 often the thing is resolved, the room is successfully recreated, lobby on and the participants manage to land in the room.

Of course, I have other customizations.

What happens exactly ? they enter an empty room or they are knocking but the room creator see nothing, ot other ?

specifically other changes to Prosody or Javascript code ?

they are knocking but the room creator see nothing.

both, in prosody the part I mentioned above in the relative lua. In javascript several graphic modifications

I need some time to lookup the code and think about that. FYI I have sometimes seen this behaviour on an install that don’t have this Prosody change so I’m not sure it’s related.

Also I notice only now that you addressed directly other users in your first post: please don’t do that. This is not Twitter, it’s a forum and it’s not right to put moral pressure on users of your choosing. I was the person who posted this code here.

I have not exerted any moral pressure. I simply added the two people who have often replied to my posts, satisfactorily. It was certainly not my will to disrespect someone.

Anyway, thank you for your commitment and I hope you can help me.
Thank you

I can’t speak for these people, this is my opinion, but when I give a reply to a question, I give it to everyone by posting it on a public forum; I don’t want to specifically help the original poster, it’s only a side effect, and said poster has no right to expect me to be his personal coach.

1 Like

Why are you doing it on set affiliation?

I copied that bit of lua code from another thread … is that wrong?

In custom modules we use we fire an HTTP request on muc-room-pre-create which then fires module:fire_event("create-lobby-room", { room = room; }); on response. That is earlier in the process when jicofo is first attempting to join.
While, I suspect, your code is triggered when jicofo promotes a participant to owner … or something like that, the order of events is not the same …
The lobbyRoomJid is read by moderators when joining the room: jitsi-meet/mod_muc_lobby_rooms.lua at b084aae212fa5328cb72e51368272eb1f519dda6 · jitsi/jitsi-meet · GitHub
Maybe in your changes the lobby room is set later.

I think I put the piece of code in the place where it was recommended. I am attaching the mod_muc_lobby_room.lua to explain better.
mod_muc_lobby_rooms(5390).txt (16.0 KB)

I reloaded the file because I had the wrong version … I put the one that is currently in production linked to the stable version 5390 of jitsi meet

yes, that was the idea. Just tested it again and it still seems to work.

@Marco_Scammacca

I have no idea why this piece of code should not work reliably for you. Could you try to setup the little utility that I join to this post and use it when you can reproduce the problem, that is, the waiting user is spinning but the moderator is not displaying the notification.

# needs admin_telnet prosody module
DOMAIN=$(basename /etc/jitsi/meet/*.js | sed s/-config.js// )
ROOM=$1
TYPE=$2
if [ "$TYPE" == "" ]; then
    TYPE="conference"
fi

echo $ROOM \(main room\):
echo
netcat localhost 5582 <<EOF | grep -aoP "(?<=${ROOM}@${TYPE}.${DOMAIN}/).+"
> for k, v in pairs(hosts["${TYPE}.${DOMAIN}"].modules.muc.get_room_from_jid("${ROOM}@${TYPE}.${DOMAIN}")._occupants) do; print(v.nick.." "..v.jid.." "..v.role.." "..(v.sessions[v.jid]:get_child_text('nick', 'http://jabber.org/protocol/nick') or '')); end
bye
EOF

if [ "$TYPE" != "conference" ]; then
    exit 0
fi

echo

echo $ROOM \(lobby\):
echo
netcat localhost 5582 <<EOF | grep -aoP "(?<=${ROOM}@lobby.${DOMAIN}/).+"
> for k, v in pairs(hosts["lobby.${DOMAIN}"].modules.muc.get_room_from_jid("${ROOM}@lobby.${DOMAIN}")._occupants) do; print(v.nick.." "..v.role); end
bye
EOF

sorry for asking you to copy and save it manually but the darn forum software gives me an error everytime I try to attach it. Enable the mod_admin_telnet module in the host config; restart prosody, make the script executable and call it by, if you have named it ‘lstocc’:

lstocc room_name

it should display in the main room: focus (aka jicofo) and the moderator, and in the lobby room the moderator (waiting for new users).

When the user click to enter the lobby, there should be then 2 users in the lobby as seen by calling again the utility. If not (the moderator is still alone in the lobby) there is a problem in the user entering the lobby. If yes, the new user presence is not forwarded to the moderator. I need this info to understand what is happening.

1 Like

yes it could be a timing problem. I don’t quite see how it could happen but I understand that events can come in unordered way can be a problem. I need to think about it.

Thank you for the tips and advice on how to check the flow. I will do it.
Meanwhile, I want to give you some further information:

In our production solution for now we have the version of our code written on stable 5390. Previously we activated the lobby on the javascript side with the toggleLobbyMode (true) when someone started a room.
This led to the anomaly where the room could in some cases become the property of a participant who was waiting …
(latency problem between starting the room and subsequent enabling of the lobby, at that juncture some participant who was waiting could enter and become the moderator …)

To kill the latency issues, we opted for the solution of server-side lobby startup with the above hook.
It is from this moment that these cases of “ghost room” sometimes occur, which are recognized as existing by those looking for it but not reachable by knocking.

Now we are working in parallel on the version on stable 6865 but we have to fix some bugs to be able to definitively bring it into production. That’s why we have the stable 5390-based version in production.

Thank you for the tips and advice on how to check the flow. I will do it. Meanwhile, I want to give you some further information:

In our production solution for now we have the version of our code written on stable 5390. Previously we activated the lobby on the javascript side with the toggleLobbyMode (true) when someone started a room.
This led to the anomaly where the room could in some cases become the property of a participant who was waiting …
(latency problem between starting the room and subsequent enabling of the lobby, at that juncture some participant who was waiting could enter and become the moderator …)

To kill the latency issues, we opted for the solution of server-side lobby startup with the above hook.
It is from this moment that these cases of “ghost room” sometimes occur, which are recognized as existing by those looking for it but not reachable by knocking.

Now we are working in parallel on the version on stable 6865 but we have to fix some bugs to be able to definitively bring it into production. (like this When I decide to enter a room with the video off, then I activate it later, no one sees me)

That’s why we have the stable 5390-based version in production. Maybe that’s the problem?

For the moment, thank you for your help

Now we have had the stable version 7001 in production for a couple of months and just today the problem of not activating the lobby in a room has returned. Do you have any news on this?