Matching and game start

each player reserves the same RoomId · the second join flips the room to Running and pushes the start notify

Matching and game start each player reserves the same RoomId · the second join flips the room to Running and pushes the start notify MatchBingoReq Relay through binding MatchBingoApiReq ReserveBingoRoomReq ReserveBingoRoomRes Get or create Room Ready MatchBingoRes(WaitingForPlayers) — after registering deferred join MatchBingoRes Join Player 1 (deferred, after handler return) Join accepted MatchBingoReq Relay through binding MatchBingoApiReq ReserveBingoRoomReq Same RoomId and settings [par] MatchBingoRes(WaitingForPlayers) MatchBingoRes [par] Join Player 2 (deferred) BingoGameStartedNotify (State = Running) BingoGameStartedNotify BingoGameStartedNotify BingoGameStartedNotify BingoGameStartedNotify BingoGameStartedNotify Player 1 · Sequence participant Player 1 Player 2 · Sequence participant Player 2 Session · Sequence participant Session Player Actor 1 · Sequence participant Player Actor 1 Player Actor 2 · Sequence participant Player Actor 2 API · Sequence participant API Matchmaking · Sequence participant Matchmaking Room · Sequence participant Room

Participants (mermaid full names)

  • • Player 1/2 = Player Client 1/2; Player Actor 1/2 = Play / Player Actor 1/2; Room = Play / Room; Session and API as labeled.
  • • API requests a reservation from the level bucket's Matchmaker Instance Spot; the Matchmaker creates a waiting room in Redis and returns the RoomId and settings. When player-2 runs the same process, Redis returns the same reservation.

Deferred join and parallelism

  • • Each Player Actor registers a deferred Room join (mermaid Actor self-message) and responds with the WaitingForPlayers projection. mermaid Note over Actor1,Room: the handler returns, then the deferred join runs — so MatchBingoRes alone does not prove the join completed.
  • • For player-2 the response branch and the deferred-join branch run in parallel (mermaid par 'Match result' ‖ 'Deferred join after handler return'). Once the second Actor join finishes, the Room sets State = Running (mermaid Room self-message) and BingoGameStartedNotify is the authoritative game-start completion.
  • • The Location Store handles room-owner lookup and remote join; Reservation Redis doesn't decide which Play node owns the room. A concurrent GetOrCreate caller waits for the single Creating authority to become Ready.
  • • The join callback waits on API's record lookup via Yield; on resume it re-checks Finished/membership before changing state. The Observer doesn't look up the player record.