matchmaking system overrides matches

how to reproduce the bug:

log in a user with the sync phrase x log in a different user with the sync phrase y log in a user with the sync phrase x log in a different user with the sync phrase y

expected result:

two matches should be generated, one for each sync phrase, x with x and y with y the client of each player stores the match that was assigned to it player 1x gets assigned match 1 player 2x gets assigned match 1 player 1y gets assigned match 2 player 2y gets assigned match 2

actual result:

this are the values that the endpoint [post] "matchmaking/searchForOponent" returned to the client: player 1x gets assigned match 1 player 2x gets assigned match 1 player 1y gets assigned match 1 player 2y gets assigned match 2

the next console logs show the way this bug was recreated: Queue { syncronization_phrase: 'x', items: [ Player { name: 'player 1x', key: 'KIUtr' } ] } Queue { syncronization_phrase: 'y', items: [ Player { name: 'player 1y', key: 'iBVHm' } ] } Queue { syncronization_phrase: 'x', items: [ Player { name: 'player 1x', key: 'KIUtr' }, Player { name: 'player 2x', key: 'vvS9G' } ] } creating match Player { name: 'player 1x', key: 'KIUtr' } Player { name: 'player 2x', key: 'vvS9G' }
Queue { syncronization_phrase: 'y', items: [ Player { name: 'player 1y', key: 'iBVHm' }, Player { name: 'player 2y', key: '2BcY6' } ] } creating match Player { name: 'player 1y', key: 'iBVHm' } Player { name: 'player 2y', key: '2BcY6' }

explanation:

the matchmaking assigns the ID of the match as soon as a player starts the matchmaking by predicting the ID of the next match. But matches are created when an opponent is found, not when a player starts looking for one. So unless the two players are logged in succession, that prediction will be wrong. And all requests to the server made by that client will fail, because the ID given to it does not match the one actually assigned to it in the server.

severity assessment:

Critical for deployment Non blocking for development, given that the problem does not exist in regular development conditions

SNeiman501 / Stratego-REST-API