This is an old revision of the document!
Table of Contents
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.
| Availability | Compatible room updates after v6.7 adoption |
|---|---|
| Documentation status | Available; v6.7.0 deployed October 1, 2026 |
| Behavior reference | v6.7.0 · reviewed 2026-10-01 |
What players will notice
An update waits for the affected room to be empty and idle continuously for at least 30 seconds. Spectators count as occupants. The bot does not deliberately interrupt a match to install a room update.
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.
What happens during a handoff
- Check the candidate's sealed release, dependencies, protocol, shared database schema and available memory.
- Wait for that room's empty/idle window. Both the worker's fresh status and the supervisor's roster must agree.
- Start and check the candidate while the old worker continues serving.
- 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.
- Confirm the old room has closed before replacing its worker. Start the new room privately and wait for healthy readiness before publishing it.
- Record its actual version, then continue with the next eligible room.
Which changes qualify?
| Change | Update policy |
|---|---|
| Compatible room commands, replies and map-selection logic | One room at a time |
| Compatible versioned map catalogs | New worker uses its pinned catalog; old workers keep theirs |
| Shared account, referee, HTTP, Discord, supervisor or protocol code | Coordinated upgrade |
| Python interpreter or dependency environment changes | Coordinated upgrade when fingerprints differ |
| Persistent-store implementation, database schema or migrations | Coordinated storage review and upgrade |
| Unexpected schema change or edited sealed release | Candidate refused; existing workers retained |
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 first v6.7 adoption
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.