Which cache-busting strategy reliably recovers a Blazor WebAssembly app from a failed deployment?

The short answer

The most reliable recovery trigger is a server-published version token that the client polls and compares, followed by a full page reload on mismatch. Query-string cache busting alone is not dependable, and the PWA service worker update flow is reliable only if you actually ship a PWA. The version-check pattern works in every hosting model, including plain static hosting behind a CDN.

Why the alternatives fall short

Query-string busting (app.dll?v=1.2.3) only helps if the HTML or boot manifest that references the DLL is itself re-fetched. With aggressive headers like Cache-Control: immutable on _framework/*, or in private browsing sessions with odd cache partitioning, the browser can keep serving the old boot JSON and old DLLs regardless of your query string. The service worker flow (registration update, activate, reload) is solid, but only exists in PWA builds — a standard Blazor WASM deployment has no service worker at all.

The recommended pattern (.NET 8)

1. Publish a version token with each deployment — a static version.json containing a build hash or timestamp works, or reuse blazor.boot.json, which already changes on every build.
2. Serve that file with Cache-Control: no-store so the client always reads the live value.
3. On startup (and optionally on a timer or after a failed fetch), the client fetches the token and compares it to the value stored in sessionStorage or captured at boot.
4. On mismatch, persist any critical transient UI state, then call NavigationManager.NavigateTo(uri, forceLoad: true) or location.reload(). The reload re-fetches the boot manifest and all assemblies fresh.

The client can detect the mismatch entirely on its own — no server push is required. The server only needs to publish the new token as part of the deploy.

Your Blazor Server assumption

Yes, that's essentially correct for .NET 8. A circuit holds in-memory state tied to the server process and assembly set. If the server is redeployed mid-circuit, the reconnection handshake fails and the client falls back to its reconnection UI, ultimately requiring a full reload; circuit state is lost. There is no cross-version circuit resync. So the same version-check-plus-reload pattern gives you a consistent recovery story on both hosting models.

Verifying it in the Network tab

Beyond checking DLL URLs, verify these:

• The version token request returns 200 with no-store and is never served from disk cache or the service worker.
• After a simulated stale deploy (old DLLs, new token), the client reloads and the subsequent blazor.boot.json and .dll requests show fresh responses — status 200, not "(from ServiceWorker)" or "(disk cache)".
• In Application → Service Workers (PWA only), confirm the worker reaches "activated" after reload.
• Repeat in a private window to confirm the flow doesn't depend on a warm cache.

Caveats

If you're behind a CDN, confirm it doesn't cache your version endpoint or strip query strings. And persist unsaved user input before forcing the reload — recovery shouldn't destroy user data. One open detail that could change this recommendation: if your app is already published as a PWA, the built-in service worker update flow may be sufficient on its own, and you'd only need the version check as a belt-and-braces trigger.