ada-blazor-wasm-api-integration

Manually constructing HttpClient with a DelegatingHandler leaves InnerHandler null in WASM, since there is no HttpClientFactory to chain it. Instead, have the auth service set DefaultRequestHeaders.Authorization directly on a shared singleton HttpClient.

Relative paths like api/posts resolve against HttpClient.BaseAddress, which is the frontend origin, so the request never leaves the frontend. Route every cross-backend call through one URL-resolving service that prefixes the configured apiBaseUrl.

Set DefaultRequestHeaders.Authorization on the shared HttpClient from your auth service whenever the token changes, using AuthenticationHeaderValue with the Bearer scheme. Public endpoints simply ignore the header, so no per-request handler chain is needed.

The ASP.NET Core dev server serves wwwroot files with ETags, so the browser reuses the cached response. Restart the dev server or use a cache-busting query, and verify what the browser actually receives rather than what curl shows.

AddScoped in Blazor WASM behaves as a session-long singleton, so cached content sources serve stale data after writes through another path. Drop session caching for mutable backend data and re-read from the API, which is the single source of truth.

No. SDK 6.0.x ships the C# 10 compiler, so raw string literals produce CS8652 even with LangVersion=latest. Write test JSON as escaped interpolated strings instead.