Issue
A player calls MatchmakerService.Instance.DeleteTicketAsync to cancel matchmaking, but they are still allocated a server and placed into a match. The DeleteTicketAsync method returns a success response, suggesting the cancellation was successful.
Cause
This behavior is caused by a race condition where the Matchmaker service finds a match and begins server allocation before it processes the ticket deletion request.
The success response from DeleteTicketAsync confirms that the ticket object was successfully deleted, not that the matchmaking process was cancelled. Once a match is created, the ticket becomes irrelevant. Deleting it at this stage will not stop the match from proceeding because the allocation has already happened.
Resolution
There is no method to guarantee that a match won't be found between checking a ticket's status and deleting it. However, you can mitigate this by checking the status before deletion and implementing strategies for handling post-match cancellations.
Check Ticket Status Before Deletion Before calling DeleteTicketAsync, poll the ticket's status. If the status shows a match has already been found, the client should prepare to join the match rather than attempting to cancel. While it is an edge case, a match can still be created in the brief moment between your status check and the deletion call .
Handling Post-Match Cancellations If a player wants to cancel after a match has already been made, consider the following options:
- Deallocate the server: This is appropriate if the leaving player is essential for the match to start .
- Mark the player as absent: This is useful if the game can proceed without the player, such as by substituting a bot.
- Use Backfill: If your game supports it, use backfilling to replace the player who cancelled with another player from the queue. This avoids wasting the allocated server resources.
If you encounter any issues or have further questions, please feel free to reach out for assistance via portal.