No FlexMatch event notification is sent if a queue placement times out

In certain scenarios, potential matches may be made through FlexMatch even when there are no available server processes in any of the fleet destinations in the queue attached to the matchmaker. In this case, assuming match acceptance is not required (PotentialMatchCreated) or if all the players needed for a match accept the match (AcceptMatchCompleted), I believe FlexMatch/GameLift waits until either a server process opens up in one of the fleets in the queue or the resulting queue placement times out.

In the former case (MatchmakingSucceeded), when a server process becomes available for hosting a game session, the matchmaking tickets will be updated with an event of type MatchmakingSucceeded.

In the latter (queue placement times out), when a server process does not become available for hosting a game session before the queue placement times out, no event notification is sent for the requests/tickets involved in the match that the queue placement timed out for. I know that we can make assumptions knowing the queue timeout and matchmaking request timeout values, and that we should try to avoid these kinds of situations from happening in general by implementing the right auto scaling policies and making sure we have enough hosting resources to meet player demand/traffic. But shouldn’t there be a FlexMatch event notification in this case? Perhaps of type MatchmakingTimedOut?

Thanks in advance!

Hi @chrisgong,

The current behavior of FlexMatch when queue placement times out is that the Matchmaking ticket is resubmitted and FlexMatch continues to try to place the match until the ticket itself times out (then a MatchmakingTimedOut event would be emitted).

If I understand correctly, what you’re looking for is another event to be emitted when Queue Placement times out and the ticket is reingested into the ticket-pool. In this case the MatchmakingTimedOut wouldn’t be the correct event since the matchmaking would still be ongoing, but I can cut a feature request for a new event to be emitted in this case. Would that solve your issue?

Hey @Nathan, thanks for responding. I believe what happens currently when a queue placement times out is that the matchmaking ticket doesn’t get resubmitted, so FlexMatch doesn’t try to continue to place the players in the ticket in a new match. And ultimately there would never be another event. For example, with this ticket, id = 354ee6b3-c823-4924-8cb3-449ed7325fb8, the ticket never got resubmitted after the queue placement timed out.

However, your proposed feature request would be useful, having an event be emitted, perhaps of type MatchmakingSearching, when the ticket gets reingested into the ticket pool. I’m just currently questioning whether the ticket does indeed ever get reingested in this scenario.

@chrisgong Can you provide the MatchmakingConfiguration ARN (with name, region, and accountId) for that ticket (id = 354ee6b3-c823-4924-8cb3-449ed7325fb8) ?

I’ll look into what happened to it and why it wasn’t re-ingested in this case.

Hey @Nathan, here’s the matchmaking configuration arn,

arn:aws:gamelift:us-east-1:952234540844:matchmakingconfiguration/GameLiftTutorialMatchmaker

Thanks again.

I can’t find any tickets with ID 354ee6b3-c823-4924-8cb3-449ed7325fb8 belonging to 952234540844 in us-east-1.
Is it possible that this is the notification event ID and not the ticketID? If so could you provide the ticket ID instead.

If this is, infact, the matchmaking ticketId one more thing that could help narrow this down is the approximate time the ticket was submitted.

Thanks!

That is one of the tickets in the potential match. It was created at time 2020-08-10T09:22:18.208Z.
The other ticket in the match had an id of 4873c8e4-fca1-47fd-b936-8a52ae47325b and a start time of 2020-08-10T09:22:19.866Z.

Hey @chrisgong – the team has what it needs to understand what is going on here, and we are investigating. It might take a bit, and we will update once we have a better understanding of what is happening.

1 Like

Hello again!

Sorry for the delay in response. Were the two provided matchIds the only two matches created during this timeframe?

The matchmaker looks to be closed because there are no incoming requests for a very long period of time and this caused the MatchmakingTimedOut event to not be emitted.

I would recommend setting the queue timeout to be a shorter value (5 min) if you are attempting to do this without regular traffic.

1 Like

Hey @Kenneth, thank you so much! Setting the queue timeout to a much lower value makes it so that a MatchmakingTimedOut event notification occurs when the queue placement times out.