---
type: Task
status: AI Gen TODO
category: QA
isAgentGenerated: "true"
---

# Test: Network Resilience and WASM Loading

## Description

Verify the Blazor WASM app handles network failures gracefully — showing loading states, error boundaries, and retry behavior when `dotnet.js`, `.wasm` files, or `.dll` resources fail to load.

## Rationale

The app is a Blazor WASM single-page application that downloads the .NET runtime (`dotnet.js`, `dotnet.wasm`) and assemblies on first load. If any of these requests fail (server down, CDN outage, flaky connection), the entire app breaks. No existing test covers this failure mode; they all assume the dev or production server is reachable.

## Playwright Feature

This test uses **`page.route()`** (route interception) to selectively block or delay specific resource types:

| Test Case | Interception |
|---|---|
| `dotnet.js` fails to load | `page.route('**/dotnet.js', route => route.abort())` |
| `.dll` assembly fails | `page.route('**_framework_**', route => route.abort())` |
| Slow network | `page.route('**', route => route.continue({ delay: 5000 }))` |
| Timeout during WASM init | Combine slow network with reduced navigation timeout |

### What to Assert

- An error boundary element (`.blazor-error-boundary`, `#blazor-error-ui`) becomes visible.
- A user-facing message like "An unhandled error has occurred" or "Retry" appears.
- The `window.dotnet` global is undefined (runtime never loaded).
- The page body is **not** a blank white screen (user sees a styled error, not a crash).
- Clicking a "Retry" button triggers a page reload.

### Variations

- Block only `dotnet.wasm` but allow `dotnet.js` (tests partial-load scenario).
- Block `.pdb` symbol files (tests debug vs. release build quality).
- Simulate offline mode with `context.setOffline(true)` for full app navigation testing.