OnRoomJoin\OnRoomAdded order

[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?

[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

[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

[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!

[Kkkosatkin]

SFS2x version is 2.19.0, thank you

[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.

[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

[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

[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

[Kkkosatkin]

Bug is caused when 10 different clients call quickJoinOrCretae simultaneously (parallel) at same time and all this clients listen games group

[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.

[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

[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

[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

[Lapo]

Thanks.
We'll post an update after testing the use case.

Cheers