fix(cover): follow connect-URL flips in library cover backfill#952
Merged
Conversation
The native cover backfill was configured once with a snapshot of the runtime connect URL. When a laptop moved off the LAN, the smart endpoint switch flipped the sticky connect URL to the public address (playback/UI covers rebuild it per request and followed it), but backfill kept fetching from the now-unreachable local address — flooding the log with "error sending request" failures. Make the connect cache observable (notify on effective flips) and have the backfill hook reconfigure when the resolved URL changes, forcing a pass so the .fetch-failed backoff from the stale address is cleared and those covers retry on the reachable endpoint.
Frontend reconfigure alone didn't fully cover the boot case: at startup the first backfill pass starts on the primary (LAN) URL before the reachability probe resolves, so when the probe flips to public the forced rerun was dropped by the pass_running guard and the slow LAN pass (every cover timing out) ran to completion with nothing re-running on the reachable address. set_session now bumps a session generation; the running pass checks it on every focus gate and abandons promptly when the URL flips (same server_index_key, new rest_base_url). try_schedule_full_pass records a rerun when a pass is in flight and drains it once the abandoned pass returns, so a fresh forced pass runs on the new address.
…it into the queue The backfill worklist no longer carries a URL. Each cover fetch reads the current reachable address live from a single worker cell, so a LAN↔public flip is honoured even by the pass already in flight — its remaining covers download against the new endpoint without aborting/rebuilding the worklist. - Drop rest_base_url from CoverBackfillSession; add live base_url cell read in ensure_one. Remove the session-generation abort machinery (no longer needed). - New lightweight library_cover_backfill_set_base_url command pushes the URL on every connect-cache flip; a real change clears the stale .fetch-failed backoff and runs a forced pass so covers that timed out on the old address retry. - Split useLibraryCoverBackfill into a configure effect (server/creds/strategy) and a flip effect that only pushes the URL. - Keep a single rerun_pending flag for the boot case (flip mid-pass), since the finished pass re-arms the idle gate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On a dual-address server (LAN + public), the smart endpoint switch picks the reachable connect URL and keeps it sticky in a session cache. Playback and on-demand UI covers rebuild
restBaseUrlper request from that cache, so they follow a flip. Library cover backfill is configured once in Rust with a snapshot of the URL and is never re-triggered.Result: when a client is off the LAN — either started that way, or moved off mid-session (internet still up, music playing via the public address) — backfill keeps hitting the now-unreachable
http://192.168.x.x:4533and floods the runtime log witherror sending request for url ...for every album/artist cover.The boot case is the tricky one: at startup the first backfill pass begins on the primary URL before the reachability probe finishes (the LAN ping has to time out first). When the probe then flips the cache to public, a naive reconfigure's forced pass is dropped by the
pass_runningguard, and the slow LAN pass (every cover timing out) runs to completion with nothing re-running on the reachable address.Fix
Frontend
serverEndpoint.ts) observable — notify subscribers only on an effective change (sticky URL set to a different endpoint, dropped on all-fail, or invalidated).useLibraryCoverBackfillreads the resolved connect URL viauseSyncExternalStoreand reconfigures the native session when it flips, forcing a pass so the.fetch-failedbackoff from the stale address is cleared and those covers retry.Rust backfill worker
set_sessionbumps a session generation; the running pass captures it and abandons promptly on every focus gate when it changes (sameserver_index_key, newrest_base_url) — so the stale-address pass stops instead of grinding through every cover.try_schedule_full_passrecords a rerun when a pass is already in flight and drains it once the abandoned pass returns — so the boot-time LAN→public flip still yields a fresh forced pass on the reachable address.UI/playback paths already follow the switch (
connectBaseUrlForServerper request) — unchanged.Test plan
serverEndpoint.test.ts: notifies on first resolve + on flip; silent when the sticky URL is unchanged; notifies on invalidation only when an entry existed. 61/61 pass.tsc --noEmitclean;cargo check -p psysonicclean.