Skip to content

fix: ready once, then hands off — a server that never readies is invisible#61

Merged
hbrombeer merged 1 commit into
mainfrom
worktree-ready-once
Jul 13, 2026
Merged

fix: ready once, then hands off — a server that never readies is invisible#61
hbrombeer merged 1 commit into
mainfrom
worktree-ready-once

Conversation

@hbrombeer

Copy link
Copy Markdown
Member

Matchmaker-managed servers never entered the pool.

Agones only moves a GameServer out of Scheduled when it calls ready(). #60 removed that call entirely — so the fleet sat there looking perfectly healthy while, to an allocator, it did not exist. Every allocation came back UnAllocated, and no match could ever be placed.

Verified live in vcluster-dahendriik: the duel fleet's GameServer stayed in Starting indefinitely, READY 0.

What #60 got right, and what it over-read

What must not happen is re-readying a server that is already allocated — its players are seconds away, and handing it back lets a second match land on it. That was the real bug, and it stays fixed: no readiness loop, no player listeners, no ready() on empty.

But "keep your hands off the state" was too broad a reading. The server has to enter the pool once, or it is not a server at all as far as the matchmaker is concerned.

So: ready exactly once, then never touch the state again. Ending the match remains the gamemode's job (SDK.Shutdown).

Both platforms (paper + minestom). The GameServerOwnership KDoc — which said "no ready()" and is what drove the mistake — is corrected in the same commit.

…sible

Matchmaker-managed servers never entered the pool. Agones only moves a
GameServer out of Scheduled when it calls ready(), and #60 removed the call
entirely — so the fleet sat there looking perfectly healthy while, to an
allocator, it did not exist. Every allocation came back UnAllocated and no
match could ever be placed. Verified live: the duel fleet's GameServer stayed
in Starting indefinitely.

Keeping our hands off the state was too broad a reading. What must not happen
is re-readying a server that is ALREADY allocated — its players are seconds
away, and handing it back lets a second match land on it. That is the bug #60
fixed, and it stays fixed: no readiness loop, no player listeners, no ready()
on empty.

So the server readies exactly once, to enter the pool, and never touches its
state again. Ending the match remains the gamemode's job.

The KDoc that said "no ready()" is corrected too — it is what drove the
mistake.
@sonarqubecloud

Copy link
Copy Markdown

@hbrombeer hbrombeer merged commit e8bc87f into main Jul 13, 2026
3 checks passed
@hbrombeer hbrombeer deleted the worktree-ready-once branch July 13, 2026 13:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant