PoolRotater Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== v7.3.4 — Catalog and update recovery ======

Published October 26 UTC on [[https://github.com/Aves-Knoot/poolrotater-v7-pilot/releases/tag/v7.3.4|GitHub]] and the signed pilot update feed. This is a controller update from the exact published v7.3.3 runtime. Existing hosts retain their settings, OAuth authorization, enrollment, catalogs, ratings and history; they use their existing automatic-update policy.

===== What changed =====

  * Temporary catalog-transfer failures receive up to three bounded attempts using the verified partial download/cache. Certificate, hash, schema, identity and policy failures remain refused.
  * After a settled, verified upgrade, managed reconciliation refreshes the independent recovery helper's runtime binding through committed lineage. It preserves recovery permissions and does not restart healthy rooms.
  * Empty-room maintenance retries known local pre-dispatch deferrals. Unknown dispatched mutations remain fenced; they are not blindly repeated.
  * Finite preparation/restoration diagnostics retain the primary failure without exposing credentials or arbitrary exception text.

Taiko and the ratings scheduler fixes introduced in [[updates:v7_3_3|v7.3.3]] are retained. This patch does not change existing room types, titles or difficulty settings. Full prepared Taiko/latest-Standard catalogs remain available automatically.

===== Automatic rollout =====

The signed feed offers v7.3.4 to v7.3.3 hosts. Empty siblings drain while occupied rooms continue; controller installation waits for all required rooms to be empty and bookings clear. Deliberately stopped slots stay stopped. Published, downloaded and queued are distinct from installed: [[status:start|Live Lobbies]] shows current room versions.

No new install command, OAuth setup, enrollment or rescue script is required for this qualified v7.3.3-to-v7.3.4 path. Existing uncertain transactions remain guarded rather than being erased.

===== Validation and limits =====

The exact installed donor path passed using all six full-sized catalogs and invented providers/test credentials. It verified occupied-match and booking protection, stopped-slot preservation, a valid configuration edit while waiting, interrupted runtime-download resume, interrupted-helper recovery, native commit, post-upgrade reporting/ratings/statistics, Discord routing and scheduled recovery-pin refresh. Runtime SHA-256: ''1392bb5226526228c6f5d02803f1cfaac5dc438ee7be403c0dd570469d1006ce''.

298 affected tests, 223 maintenance integration tests and 45 overlapping focused checks passed; these counts are not additive. Initial health/pin observations needed a later read-only health sample and a quiescent observation helper; failed observations remain retained. The subsequent explicit donor teardown had an uncertain fake-room close and was retained separately from upgrade acceptance. It is not evidence of clean shutdown. The earlier R25 pre-admission controller-interruption failure also remains a documented historical limitation. No zero-failure guarantee is made.

The owner L3 Taiko pilot has three completed scored matches and one earlier abort in live history; each completed match had one participant. This establishes observed gameplay, not full multiplayer or every-command acceptance. Website cards show current ruleset/settings, map art, players, queue and approximate timing; Discord omits map progress. If only hit length is available, the website labels it **Play length** rather than showing unknown length.

===== Current deployment and website follow-up =====

The owner and Strohm completed the normal automatic update to v7.3.4 with healthy intended rooms and preserved stopped slots. The owner verified all six unchanged catalog bindings and all 20 retained configuration files: only four room version stamps changed. The actual Taiko website/Discord card now matches the restored room, including artwork and qualified length.

Xikeon's outgoing v7.3.3 controller entered ''update_maintenance_outcome_requires_review'' before incoming installation. Standard remains running; the already-drained 4K/7K rooms remain stopped. This is an unresolved deployment issue, not accepted automatic-upgrade success. No uncertain state has been cleared and no occupied room has been force-closed. Received local diagnostics and logs identify an automatic room refresh during empty-room maintenance: the worker reported ''room_changed'', while both Mania rooms closed cleanly and no commit was admitted. Xikeon still needs a guarded local maintenance/upgrade pass because the installed recovery helper refuses pre-admission completion. Preventive hardening is tested in development and is not yet published.

An independent website patch increases the owner status-request deadline from five to 15 seconds and preserves last-known identity/map/settings briefly, labelled as delayed. It never retains expired live player counts or playback progress. Semantic QuickJS tests cover reserved slots, transient failures, bounded expiry, newer offline observations and malformed data; the deployed compiled bundle is verified. No lobby restart was required.

A further website-only correction fixes a JavaScript scope error that prevented owner status polling from starting and left cards showing “Status temporarily unavailable”. The actual served page now passes Chromium checks with no JavaScript errors, repeated successful status requests and all four slots rendered correctly. Five focused JavaScript tests passed. No lobby or service restart was required.