Page 1 of 2
OnRoomJoin\OnRoomAdded order
Posted: 15 Dec 2025, 16:17
by Kkkosatkin
Hello! We’ve encountered an issue with QuickJoinOrCreateRequest and callback handling — sometimes the OnRoomJoin callback is triggered before the room is added (the OnRoomAdded event arrives later). Could this issue be related to join/create calls being executed at the same time, where multithreading breaks the expected call order?
Re: OnRoomJoin\OnRoomAdded order
Posted: 16 Dec 2025, 07:14
by Lapo
Hi,
can you give use more info?
What version of SFS2X are you working with?
What is the client API (and version) you're using?
Thanks
Re: OnRoomJoin\OnRoomAdded order
Posted: 17 Dec 2025, 11:26
by Kkkosatkin
During matchmaking, all players in the lobby send a "quickJoinOrCreateRequest" simultaneously.
When the "OnRoomJoin" event is received, an SFSRoom from the event argument is saved in field "gameLastJoinedRoom". After that, the "onRoomAdded" event is triggered. In this event, the SFSRoom argument may contain outdated data (including an incorrect list of players). As a result, room properties become inconsistent. For example, the isJoined property may have an incorrect value, which causes incorrect room state handling.
SFS2x version - I'm not sure, where I can see that?
Client api version 1.8.5
Re: OnRoomJoin\OnRoomAdded order
Posted: 17 Dec 2025, 11:36
by Lapo
SFS2x version - I'm not sure, where I can see that?
In the log files you'll find something like this, at the bottom of the boot phase:
Code: Select all
_____ _____ _____ ___ __ __
| __| __| __| |_ | | |
|__ | __|__ | | _|- -|
|_____|__| |_____| |___|__|__|
_____ _____ _____ ____ __ __
| __ | __| _ | \| | |
| -| __| | | |_ _|
|__|__|_____|__|__|____/ |_|
[ Version: 2.20.5 ]
(c) gotoAndPlay() 2012-2025
Also you can find it by connecting via AdminTool
Let us know!
Re: OnRoomJoin\OnRoomAdded order
Posted: 17 Dec 2025, 11:44
by Kkkosatkin
SFS2x version is 2.19.0, thank you
Re: OnRoomJoin\OnRoomAdded order
Posted: 17 Dec 2025, 14:44
by Kkkosatkin
There is a missing check to verify whether a room already exists before creating a new one.
If a room already exists, should the system avoid creating it again? Currently, the room creation logic does not perform this validation, which may lead to incorrect behavior.
Re: OnRoomJoin\OnRoomAdded order
Posted: 17 Dec 2025, 15:22
by Lapo
If a room already exists, should the system avoid creating it again?
1) How is this connected to the first issue you have posted? If it's a different topic I'd be best to start a new thread.
2) It is the server does that performs these checks. Since the server doesn't allow two Rooms with the same id/name to exist the client just takes for granted what the server sends back.
If you have a situation where Rooms get duplicated on the client side, please start a new thread and provide the details as per these rules:
https://forums.smartfoxserver.com/viewtopic.php?t=16497
Thanks
Re: OnRoomJoin\OnRoomAdded order
Posted: 18 Dec 2025, 08:46
by Lapo
sometimes the OnRoomJoin callback is triggered before the room is added (the OnRoomAdded event arrives later). Could this issue be related to join/create calls being executed at the same time, where multithreading breaks the expected call order?
Is this issue happening for the side of joining player? Or from the side of the other Users already joined?
We have done a bit of load testing of this scenario from the perspective of the users already joined and we've found no way to replicate it. The test joins 30 clients at the same time via QuickJoinOrCreate and we've run over 500 cycles without any issues.
It is also unlikely in theory since messages are queued in the order they're sent and the outgoing queue is synchronized.
Let us know
Re: OnRoomJoin\OnRoomAdded order
Posted: 18 Dec 2025, 09:16
by Kkkosatkin
1) no, the same topic
2) server dont check atomic of transaction, so response of join may come before room_add - it can easily be reproduced
Re: OnRoomJoin\OnRoomAdded order
Posted: 18 Dec 2025, 09:20
by Kkkosatkin
Bug is caused when 10 different clients call quickJoinOrCretae simultaneously (parallel) at same time and all this clients listen games group
Re: OnRoomJoin\OnRoomAdded order
Posted: 18 Dec 2025, 13:15
by Kkkosatkin
For example, as shown in the screenshot, two rooms were created with the same name but different id's. The quickJoinOrCreate request was called simultaneously for all users.
Re: OnRoomJoin\OnRoomAdded order
Posted: 18 Dec 2025, 13:25
by dashanddot
Hi smartfox team - your server code is not thread safe in creation andd joining rooms - you should use mutex in begining of handler and unlock in in end - its usual case when new thread add room to list after list whas atomary checked.
it should be atomic transaction - its standart of multithreaded programming
quickJoinOrCreate should be atomic too
Re: OnRoomJoin\OnRoomAdded order
Posted: 18 Dec 2025, 16:38
by Lapo
For example, as shown in the screenshot, two rooms were created with the same name but different id's. The quickJoinOrCreate request was called simultaneously for all users.
So the QuickJoinOrCreate is called from the server side?
2) server dont check atomic of transaction, so response of join may come before room_add - it can easily be reproduced
Please provide the reproduction case.
Here are the info we need:
https://forums.smartfoxserver.com/viewtopic.php?t=16497
Thanks
Re: OnRoomJoin\OnRoomAdded order
Posted: 19 Dec 2025, 10:26
by Kkkosatkin
So the QuickJoinOrCreate is called from the server side?
- no, it's called from the client
SFS2x version is 2.19.0
Client api version 1.8.5
The issue is incorrect order of onRoomJoin and onRoomAdded events. This does not happen consistently, in some cases onRoomAdded is received after onRoomJoin.
Additionally, there is an issue where two rooms with the same name but different ids are created.
All of these issues occur when quickJoinOrCreate is called simultaneously on multiple clients after they receive a message from the chat client indicating that they should join a room.
Server side logs above in the chat
Re: OnRoomJoin\OnRoomAdded order
Posted: 19 Dec 2025, 16:56
by Lapo
Thanks.
We'll post an update after testing the use case.
Cheers