feat(web/playlists): stale-view banner + Refresh on an open system-playlist after rebuild

#980. When the daily rebuild fires while a system-playlist detail page is open, its cached data goes stale and can't be refetched in place — the playlist id rotated, so the old id 404s. serverEvents now exposes a monotonic rebuild counter; the detail page shows a "this mix was refreshed" banner with a Refresh that re-resolves the variant (systemShuffle) to the new playlist id and navigates there. No forced redirect, no auto-reload — the user refreshes on their terms. Functional behaviors were already correct (tapping a song plays it; tiles load the current mix); this closes the cosmetic list-staleness. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-20 19:48:52 -04:00
parent d05264ff80
commit e932ab438c
2 changed files with 69 additions and 1 deletions
@@ -12,7 +12,20 @@ import { user } from '$lib/auth/store.svelte';
 // deliberately do NOT yank a playing queue here — that would interrupt a
 // mid-song listen to restart the new mix at track 0.

+// Monotonic rebuild counter (#980). Bumped on every playlist.system_rebuilt.
+// An open system-playlist DETAIL page can't be invalidated in place (its id
+// rotates on rebuild — a refetch would 404), so instead it watches this
+// counter and offers a "this mix was refreshed → Refresh" affordance that
+// re-resolves the variant to the new playlist.
+let _systemRebuildCount = $state(0);
+export const systemRebuilt = {
+  get count(): number {
+    return _systemRebuildCount;
+  }
+};
+
 function onSystemRebuilt(): void {
+  _systemRebuildCount++;
  queryClient.invalidateQueries({ queryKey: qk.home() });
  // Prefix match invalidates every kind ('user' | 'system' | 'all').
  queryClient.invalidateQueries({ queryKey: ['playlists'] });