Table of Contents
v6.7.22: Hot-loadable safe-update wait
Scheduled supervisor update — not yet live at the October 5, 2026, 15:11 PDT review. The durable maintenance job was waiting for its compatible bridge to finish. Initial activation is authorized only after all four lobbies are confirmed empty and idle.
What changes
- Ordinary queued room updates wait for five continuous empty-and-idle seconds, instead of 30.
- Keeps admission locks, referee-event draining, fresh independent roster checks and guarded closure. A new arrival cancels the attempt; players are not kicked to install an update.
- Makes the deployment wait adjustable by a small local JSON file, without another supervisor restart.
- Keeps one-room-at-a-time ordinary rollouts and the existing shared account connections.
- Includes the cumulative Jump rework and maintenance bridge.
Five seconds is the eligibility wait, not a promise that the complete handoff finishes within five seconds. Relisting, match countdowns, pre-countdowns and empty-difficulty resets are separate timers and are unchanged.
Operator setting after activation
File: /opt/poolrotator-runtime/instances/supervisor.json
{"deployment_empty_seconds": 5}
Accepts finite numbers from 5 through 3600 seconds. The existing supervisor tick hot-loads the file locally; no API polling or new monitoring thread is added. Invalid JSON, unknown keys, booleans, nonfinite/out-of-range values and symlinks retain the last known good setting. Removing the file or key restores five seconds. Changing the value restarts the continuous-empty interval. The effective value appears as deployment_empty_seconds in the operator rolling-status file.
First activation
The maintenance job waits for the existing rollout, installs the compatible bridge through empty-safe room updates, then waits for all four rooms simultaneously empty and idle. It confirms private gates and drains late events before stopping the old supervisor. A new supervisor starts only after closure and clean ownership are verified. Unknown closure or startup outcomes block for review instead of starting duplicate clients or retrying blindly.
Validation passed: 780 offline supervisor tests, 770 bridge tests and service-owner read-only checks of all four catalogs. These checks did not create live test rooms or use a second authenticated account client.
Already-live duration tuning
The owner separately hot-loaded the normal 90–135-second preference and 240-second hard cap in all four rooms on October 5. That configuration does not wait for v6.7.22. Jump retains its under-90-second preference; DT uses its existing shorter preferred minimum. Details and deployment protection.