Matchmaking event of type MatchmakingSucceeded did not contain player session ids of new incoming players
Recently I believe I may have stumbled across a glitch where an event of type MatchmakingSucceeded did not have the player session ids of the new incoming players. I do want to note that this matchmaking request was a manual backfill request so I am not sure if that had anything to do with it. I just want to make sure that this is a glitch or if something I did caused this to happen. And if need be, for further investigation, I can pm someone information about the match and players involved because I have the event message recorded.
We recently deployed an improvement to the GameLift service that targets missing player session IDs in matchmaker responses. We expect missing player session IDs to no longer occur. Please let us know if you still see this issue over the next 2-3 weeks!
Can you provide matchmaking ticket ids and I can get the GameLift service team to investigate?
Yes, here are the tickets associated with the event:
b1bb51c1-d0b0-4ed2-b060-7ed3fc362fd9 a4a94c8e-7823-4b91-a029-3e8401d968b7 2f8c501a-c424-428b-a1be-5475e3b54278
I recently noticed this issue too. Players that leave the session or time out are still reported in backfill messages but don't have a player session.
Is this still going to be expected behavior or will this be changing somehow?
@REDACTEDUSER
Seems strange to have player data without a player session id on a game session update. As you mention that this is impacting players who've left / timed out on connect, this may due to the fact that your game server is currently responsible for updating the player data in this circumstance and I wonder if there is stale data being sent with the request.
Hey @REDACTEDUSER
bc459d6a-08a0-4506-b97d-6001bbe1f0b4
I believe what happened exactly was that there was a situation in which a player left the game, and a backfill request was made with the remaining players. Then, one of the remaining players also left but the backfill request in progress was not cancelled. Therefore, players could get matched with this backfill ticket that was not truly representative of the players still in the game.
I don't know if this is necessarily good or bad behavior, since I found a way around this by cancelling backfill requests whenever players leave the game. In my case, I terminate the player session when a player leaves, so eventually a new backfill request gets made with the remaining players in the game.
I looked into what happened to that ticket. It was exactly like what you described. The player session was already completed by the time the match was formed.
FlexMatch assumes the players in match making tickets are accurate, so it currently records this abnormal case and returns a ticket with missing player session IDs.
Your method of canceling the backfill request when players leave the game is the right approach.
Relevant questions
Can matchmaking event notifications of type PotentialMatchCreated and AcceptMatchCompleted be sent after those of type MatchmakingSucceeded?
Accepted Answerasked 2 years agoIs there an event for game session termination?
Accepted Answerasked 4 months agoGamelift - Current limit of instance type of c4.large have been reached
asked 4 years agoNo event after PotentialMatchCreated
Accepted Answerasked a year agoNo FlexMatch event notification is sent if a queue placement times out
asked 2 years agoCDK AWS trigger with type EVENT
asked 2 months agoOnUpdateGameSession handler function is not invoked when a backfill request is cancelled due to duplicate player ids
asked 2 years agoMatchmaking event of type MatchmakingSucceeded did not contain player session ids of new incoming players
Accepted Answerasked 2 years agoFlexMatch long matchmaking time
asked 4 months agoHow does an expansions in a matchmaking rule work?
Accepted Answerasked 2 years ago