Can Blazor WebAssembly reliably verify restored state after Service Worker cache rebuild?

Reliability of State Verification

Yes, Blazor WebAssembly can reliably verify restored state, but it is critical to understand that a Service Worker cache rebuild affects static assets (DLLs, WASM, HTML), not the browser storage (LocalStorage, IndexedDB) where application state is typically persisted. Because these are separate storage mechanisms, state remains intact during a cache rebuild unless the browser explicitly clears site data or the developer manually triggers a purge.

The Verification Strategy

To ensure the integrity of restored data—especially when a new version of the app may have changed the data schema—the most robust approach is to use a Versioned Hash strategy. Since Blazor does not provide a built-in hashing function, you must leverage the browser's native capabilities via JS Interop.

Implementation Steps

1. Hashing via Web Crypto API: Use the SubtleCrypto.digest('SHA-256', data) method. This is the most suitable strategy because it is hardware-accelerated, native to all modern browsers, and handles complex JSON strings efficiently without adding external library overhead.
2. Storage Pattern: Store your state as a composite object containing the data, a schema version number, and the SHA-256 hash of the data payload.

   {
     "version": "1.2.0",
     "hash": "a5f6...",
     "payload": { ... }
   }

3. Verification Logic: On application startup (e.g., in OnInitializedAsync), retrieve the object, re-calculate the hash of the payload, and compare it to the stored hash.
4. Handling Mismatches: If the hash is invalid or the version is outdated, treat the state as corrupted. To preserve the offline experience, implement a fallback chain: Attempt to load a cached "safe default" state first, then trigger a background fetch to synchronize with the server once connectivity is confirmed.

Assumptions and Constraints

This approach assumes that the state is small enough to fit in LocalStorage (typically <5MB). For larger datasets, IndexedDB is recommended, though the hashing logic remains the same. Be aware that localStorage access is synchronous and can block the UI thread if the payload is excessively large; for high-performance needs, perform the hashing in a separate JavaScript worker.

Verification Command

To verify if your state survives a cache rebuild during development, use the Chrome DevTools Application tab: check "Update on reload" under the Service Worker section, refresh the page, and observe if your LocalStorage keys persist while the Cache Storage is cleared and rewritten.

Diagnostic Detail Needed: Are you persisting state as simple JSON strings in LocalStorage, or are you utilizing a more complex structure like IndexedDB?