As of sometime last night (9/23) and today (9/24) our dedicated servers are no longer receiving the SESSION_MEMBER_CHANGED messages and are therefore unable to proceed after being claimed.
Hi @njupshot,
Could you please provide the session ID so that our internal team can investigate further?
Additionally, we tried to reproduce your issue using the Byte Wars sample, but the SESSION_MEMBER_CHANGED event is still being received on the DS.
We repro’d this morning.
Session ID: 400b17a090694fe6a02ef77341116f26
Pod ID: ds_01922859-f549-78fb-a60a-09979bf51ad7
Upon joining the session, the client realizes that the dedi is not ready yet and so it awaits the DS status changed notification. Upon receiving it, it then connects to the dedicated server. However, the dedicated server receives no further messages after the initial serverClaimed message.
The issue seems to only happen in the case that the dedi takes some additional time to provision which is indicative by the fact that it’s not present in the response when the client joins the session. In that case, the dedi will not receive any further messages from the hub after serverClaimed and therefore the dedi has no way of knowing which players are supposed to be in the session and therefore can’t permit said players to connect. In other words, if the server is provisioned after the client joins the session then the server won’t be notified of the session’s participants.
Hi @njupshot,
Thank you for the explanation. The SESSION_MEMBER_CHANGED event not being received by the DS is expected only if the user has already joined the session.
We recommend obtaining session information after the server is claimed so the DS can get the initial players who joined the session. If a new player joins the session later, the DS will receive the SESSION_MEMBER_CHANGED event.
Hope this answer your question.