How room updates work

v6.7 lets compatible bot updates reach an empty lobby while other lobbies keep playing. Each room runs in its own process from a pinned release, so occupied rooms can remain on their current version until their turn comes.

An update waits for the affected room to be empty and idle continuously for at least 30 seconds. Spectators count as occupants. Players are not kicked or removed to install automatic updates. An occupied room or an unknown roster blocks infrastructure closure.

When an empty room is replaced, it receives a new room ID. Old bookmarks or invites may stop working. Use Join a lobby at the top of the site or Live lobbies to find its current link. Other rooms keep their players, matches and join links during that individual handoff.

If a player arrives before the old room closes, the handoff is cancelled and the old controller resumes. A player may see different compatible versions in different room titles while an update works through the lobbies.

1. Check the candidate's sealed release, dependencies, protocol, shared database schema and available memory.
2. Wait for that room's empty/idle window. Both the worker's fresh status and the supervisor's roster must agree.
3. Start and check the candidate while the old worker continues serving.
4. Pause the old controller at a loop boundary and temporarily password-lock the empty room. Recheck occupancy and the account connection; a new arrival cancels the handoff before closure.
5. Confirm the old room has closed before replacing its worker. Start the new room privately and wait for healthy readiness before publishing it.
6. Record its actual version, then continue with the next eligible room.

The workers can write normal results to existing shared tables. Rolling candidates cannot perform destructive schema changes or silently run migrations. A rollback never overwrites the shared database with an old copy: that would discard results gathered by other rooms.

These checks prevent known compatibility mistakes. They cannot guarantee that arbitrary changed code has no bugs. Updates still need tests and review; incompatible shared changes are deliberately kept outside the per-room path.

The initial v6.7 adoption completed on October 1, 2026 through an operator-approved maintenance restart. All four old rooms were confirmed closed before the new supervisor opened their replacements. Compatible future room updates use the individual empty-and-idle safety window described above. Shared supervisor, protocol, dependency and database changes still need a coordinated upgrade.

The supervisor keeps shared account connections and coordinates room ownership. Its own version can differ from the workers' compatible versions. The wiki's verified release inventory describes a reviewed release; one account-level version notice does not prove that every room has identical code during a rollout.

See v6.7.0 release notes, technical overview, match lifecycle, and troubleshooting.