Skip to content

PrivateGameMatchController has zero test coverage — the #159 429 bug was invisible to CI #170

Description

@razam-sherwani

Dependency: READY — start now. No blockers, parallel-safe with everything else. Worth landing before #160 if you want an existing harness for that endpoint's budget tests.

Split out of #159, which is now closed by #168.

PrivateGameMatchController has zero test coverage. Nothing under src/test/ references the class, and every api/v1/game-match string in the suite belongs to GameMatchFileControllerIT / GameMatchFileDownloadIT — a different controller (game-match-file). Re-verified on staging @ d6a6a7e, i.e. after #168 merged.

That gap is why the maxQueuedPerTeam = 0 bug in #159 was invisible to CI: the full suite passed green (118 tests, 0 failures) the whole time the endpoint was 429-ing on first use.

#168 added the right regression guards for the defaulting half (LadderDefaultsTest, AdminLadderControllerIT), but the consuming endpoint is still untested. Two specific paths never execute in any test:

  • The cap check, PrivateGameMatchController.java:115currentWaitingMatches >= ladder.getMaxQueuedPerTeam()429.
  • The clamp, :122Math.min(maxQueued - currentWaiting, count). This carried a second latent bug behind the first: with the field at 0 it yields 0, so even a relaxed guard would have created zero matches. It deserves its own assertion rather than riding on the entity default.

Suggested coverage

Drive the real POST /api/v1/game-match endpoint (asserting on LadderService alone will not catch a regression here):

  1. First match on a fresh ladder succeeds — the direct regression test for Ladder creation silently sets maxQueuedPerTeam to 0, causing immediate 429s #159.
  2. Queueing past maxQueuedPerTeam returns 429.
  3. count greater than the remaining allowance is clamped to the remainder, and the response reflects the number actually created.
  4. allowUserMatches = false is rejected independently of the cap.

Worth noting for whoever picks this up: TestDataFactory.createLadder used to reproduce the production defect exactly — new Ladder() plus nine Glicko fields, never touching maxQueuedPerTeam. It now inherits the correct default from the entity via #168, so the helper needs no change; the missing piece is genuinely the endpoint tests.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Mid PriorityenhancementNew feature or requestreadyNo open blockers - can be started now

    Type

    No type

    Fields

    Stage

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions