fix(matchmaking): re-enqueue opens a new game, not the caller's own #82

Merged

owner merged 1 commits from feature/reenqueue-opens-new-game into development 2026-06-18 08:38:41 +00:00

Conversation 1 Commits 1 Files Changed 5

+39 -40

developer commented 2026-06-18 08:19:10 +00:00

Owner

Copy Link

Copy Source

Bug

Starting a random-opponent game, then starting another "random opponent" with the same variant and per-turn rule while the first was still open (no opponent joined yet), returned the same pending game — a fresh game was never created, so the player was stuck in the partment still awaiting an opponent.

Fix

Removed the own-open short-circuit (step 1) in store.OpenOrJoin. A re-enqueue now joins another player's open game (step 2) or opens a fresh one (step 3). Accumulation stays bounded by MaxActiveQuickGames, which already counts open games.

Updated the matchmaker/service/store Go-Doc comments and docs/ARCHITECTURE.md. Flipped the pinning test TestMatchmakingReEnqueueReturnsOwnOpenGame → TestMatchmakingReEnqueueOpensNewGame.

Tests

• New test verified red → green (saw the "same id" failure before the fix).
• Full backend unit + integration green; build / vet / gofmt clean.
• UI untouched: it navigates to the game id from the response; double-tap already guarded by the starting flag.

## Bug Starting a random-opponent game, then starting another "random opponent" with the same variant and per-turn rule while the first was still `open` (no opponent joined yet), returned the **same** pending game — a fresh game was never created, so the player was stuck in the partment still awaiting an opponent. ## Fix Removed the own-open short-circuit (step 1) in `store.OpenOrJoin`. A re-enqueue now joins another player's open game (step 2) or opens a fresh one (step 3). Accumulation stays bounded by `MaxActiveQuickGames`, which already counts `open` games. Updated the matchmaker/service/store Go-Doc comments and `docs/ARCHITECTURE.md`. Flipped the pinning test `TestMatchmakingReEnqueueReturnsOwnOpenGame` → `TestMatchmakingReEnqueueOpensNewGame`. ## Tests - New test verified red → green (saw the "same id" failure before the fix). - Full backend **unit** + **integration** green; `build` / `vet` / `gofmt` clean. - UI untouched: it navigates to the game id from the response; double-tap already guarded by the `starting` flag.

developer added 1 commit 2026-06-18 08:19:10 +00:00

fix(matchmaking): re-enqueue opens a new game, not the caller's own ... 9d52885a6e

A second "random opponent" enqueue with the same variant and per-turn
rule, while the caller's first game was still open (awaiting an
opponent), returned that same open game, so a player could never start a
fresh random game while one was still searching.

Drop the own-open short-circuit (step 1) in store.OpenOrJoin: a
re-enqueue now joins another player's open game or opens a fresh one.
Accumulation stays bounded by MaxActiveQuickGames, which counts open
games. Update the matchmaker/service/store doc comments and
ARCHITECTURE.md, and flip the pinning test to assert the new behavior.

owner approved these changes 2026-06-18 08:37:59 +00:00

owner merged commit 9074417762 into development 2026-06-18 08:38:41 +00:00

owner deleted branch feature/reenqueue-opens-new-game 2026-06-18 08:38:41 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

owner

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

owner (Ilia) developer

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: developer/scrabble-game#82