You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:115 — currentWaitingMatches >= ladder.getMaxQueuedPerTeam() → 429.
The clamp, :122 — Math.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):
count greater than the remaining allowance is clamped to the remainder, and the response reflects the number actually created.
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.
Split out of #159, which is now closed by #168.
PrivateGameMatchControllerhas zero test coverage. Nothing undersrc/test/references the class, and everyapi/v1/game-matchstring in the suite belongs toGameMatchFileControllerIT/GameMatchFileDownloadIT— a different controller (game-match-file). Re-verified onstaging@d6a6a7e, i.e. after #168 merged.That gap is why the
maxQueuedPerTeam = 0bug 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:PrivateGameMatchController.java:115—currentWaitingMatches >= ladder.getMaxQueuedPerTeam()→429.:122—Math.min(maxQueued - currentWaiting, count). This carried a second latent bug behind the first: with the field at0it yields0, 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-matchendpoint (asserting onLadderServicealone will not catch a regression here):maxQueuedPerTeamreturns429.countgreater than the remaining allowance is clamped to the remainder, and the response reflects the number actually created.allowUserMatches = falseis rejected independently of the cap.Worth noting for whoever picks this up:
TestDataFactory.createLadderused to reproduce the production defect exactly —new Ladder()plus nine Glicko fields, never touchingmaxQueuedPerTeam. 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.