Skip to content

CANCELLED: If current player disconnects, next turn can trigger unwanted Gist fork #24

Closed
@LearningNerd

Description

@LearningNerd

In closing issue #20, this other bug popped up! If the current player disconnects before their turn is over, in certain scenarios this causes the next player to try to fork their own Gist at the end of the next turn, resulting in a 422 error response from GitHub.

Scenario for current player disconnection bug:

  1. Player 0 connects, creates Gist, and Player 1 connects. (Server initializes previousPlayerIndex and currentPlayerIndex to 0.)

  2. First turn ends, Player 0 edits their Gist, and the second starts and passes control to Player 1. (Server's previousPlayerIndex is now 0, and currentPlayerIndex is now 1.)

  3. Player 1 disconnects on their turn, before their turn is over. (This begins the problematic part, if I continue to do client-side API calls!)

  4. Server removes Player 1 from playerList, restarts turn timer, and changes turn to pass control back to Player 0. (So previousPlayerId is now undefined because previousPlayerIndex is 1, but playerList now only contains information at index 0!)

  5. Server emits updateStateChange to clients, which receive that undefined value and thus set their previousPlayerId variable to undefined too!

  6. At the end of Player 0's turn, their client tries to fork the Gist because the condition for forking is currentPlayerId !== previousPlayerId, comparing the currentPlayer to undefined, which causes an 422 error reponse from GitHub, because Player 0 can't fork their own Gist!

This problem doesn't occur at all if Player 0 disconnects on their turn, because the server can always access index 0 of playerList array, and the rest works out nicely -- one big happy accident!

Other scenarios to explore:

  • What if there are more than two players in the game?
  • What other edge cases are there?

Possible solutions:

  • One definitive fix would be to check just before the end of every turn if the current player is the owner of the Gist or not. That would always work! (But for some reason I feel stubborn about this, hopeful that there's another way to accomplish this without adding one more condition to my code.)

  • Issue Server should fork/edit Gists on behalf of disconnected users #21 ("Server should fork/edit Gists on behalf of disconnected users") would resolve this issue as well! (I'm leaving this as a separate issue in case there's a way to fix this while still handling all API calls on the clients.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions