Table of Contents

v7.3.4 — Catalog and update recovery

Published October 26 UTC on 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

Taiko and the ratings scheduler fixes introduced in 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: 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. A read-only local guard report has been requested because the existing recovery channel refused inspection.

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.