updates:v6_7_22

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.

Release history · Update safety · Live lobbies

updates/v6_7_22.txt · Last modified: by wikiadmin

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki