aspnetcore

This is caused by a transitive dependency chain introduced in Microsoft.EntityFrameworkCore.SqlServer 10.0.11–10.0.13, which upgraded Microsoft.Data.SqlClient from 6.1.1 to 6.1.6. SqlClient 6.1.6 depends on Microsoft.Identity.Client.Broker 4.84.2, which pulls in Microsoft.Identity.Client.NativeInterop 0.20.6 — that package ships the 38 MB libmsalruntime.so in runtimes/linux-x64/native. You can verify the path with dotnet nuget why Microsoft.Identity.Client.NativeInterop. Workaround: explicitly reference Microsoft.Data.SqlClient version 7.1.1 (or later) in your project, which no longer includes this native dependency — libmsalruntime.so will disappear from the build output. EFCore.SqlServer is expected to upgrade to SqlClient 7.1.1 in a future release, which will resolve it without the manual override.

This is a middleware ordering issue. If UseRateLimiter is registered before UseStatusCodePagesWithReExecute, the rate limiter sits outside the re-execution branch and won't evaluate the re-executed endpoint's policy.

Fix — register status-code-pages middleware BEFORE routing, and the rate limiter AFTER routing:

app.UseStatusCodePagesWithReExecute("/b");
app.UseRouting();
app.UseRateLimiter();

With this ordering, re-execution runs routing again and includes the rate limiter, so it reads the newly selected endpoint (e.g. /b), acquires a fresh lease, and rejects the request when no permits remain. Note: middleware placed before the status-code-pages middleware does not run again during re-execution.

Upgrade to .NET SDK version 10.0.400 or later (released August 11). The reconnection fix originally made for .NET 11 was backported to the .NET 10 branch and shipped in this SDK version. If you still experience pause/resume or reconnection problems after updating, open a new issue on the dotnet/aspnetcore GitHub repository.

This is a regression in Microsoft.Authentication.WebAssembly.Msal 10.0.8–10.0.12. Concurrent calls such as getUser and getAccessToken can enter AuthenticationService.init before initialization completes, creating two MSAL instances. The first instance removes the saved returnUrl from sessionStorage; the second instance then completes sign-in without state, causing Blazor to fall back to Navigation.BaseUri.

Fix: upgrade to a patched release containing PRs #69735 and #69736. If a patched version is not yet available, temporarily downgrade to the last working version:

dotnet add package Microsoft.Authentication.WebAssembly.Msal --version 10.0.7

The underlying fix caches the initialization promise so concurrent callers share the same MSAL instance instead of each creating one and consuming the redirect state.

This is a regression in ASP.NET Core 10.0.9 through at least 10.0.12. DefaultPolicy.ServeResponseAsync now sets AllowCacheStorage = false for authenticated users, overriding a custom policy that enabled caching in CacheRequestAsync.

Workaround: re-assert the flag in the custom policy's ServeResponseAsync, because custom policies run after the default policy:

public ValueTask ServeResponseAsync(OutputCacheContext context, CancellationToken cancellationToken)
{
    if (context.HttpContext.User?.Identity?.IsAuthenticated == true)
    {
        context.AllowCacheStorage = true;
    }

    return ValueTask.CompletedTask;
}

Keep the existing AllowCacheStorage = true and expiration/vary-by settings in CacheRequestAsync. Use this only for authenticated responses that are safe to share across users; configure appropriate CacheVaryByRules for user-specific data.

Permanent fix: upgrade to an ASP.NET Core release containing PR #69580 and its backports (#69725 for .NET 10, #69724 for .NET 11). Verify the installed runtime with dotnet --info.