Blazor: Resilience on poor connection

[mip1983]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Hi, I've got a colleague using our Blazor application who's often on a poor connection, hitting on errors during initial load of the app.

It's the latest .NET 10/Blazor Web template with most if not all of the client components set to 'InteractiveWebAssembly'. I don't know if it's relevant, but it uses 'ResourcePreloader' and '@assets to load all the scripts inc. blazor.web.js (as is standard in the current template).

The errors we're seeing crop up in the browser console are:

blazor.web.ax6tuj8tun.js:1  Error in mono_download_assets: CompileError: WebAssembly.compileStreaming(): section (code 10, "Code") extends past end of the module (length 97426166, remaining bytes 10092657) @+1367668
_r @ blazor.web.ax6tuj8tun.js:1
(anonymous) @ dotnet.yq4sd6a9j6.js:4

Unfortunately I'm not able to repro this myself so far. I'm guessing on a lossy connection that something is failing as it's doing whatever it's doing 'compileStreaming' here. Sometimes clearing the browser cache helps, other times not (maybe a red herring and simply down to the connection in the moment).

Is there anything that can be bolstered from a resilience/retry perspective for this type of problem? Is it possible that things can get stuck in this state until cache is cleared, or is this all down to connection?

Expected Behavior

It would be great if it could attempt to recover/retry for these kinds of issues.

Steps To Reproduce

I appreciate this is a challenging one, perhaps simulating low speed/high loss on a blazor web app with 'InteractiveWebAssembly' components?

Exceptions (if any)

blazor.web.ax6tuj8tun.js:1 Error in mono_download_assets: CompileError: WebAssembly.compileStreaming(): section (code 10, "Code") extends past end of the module (length 97426166, remaining bytes 10092657) @+1367668
_r @ blazor.web.ax6tuj8tun.js:1
(anonymous) @ dotnet.yq4sd6a9j6.js:4

.NET Version

10.0.103

Anything else?

This is on the deployed production application so IDE etc. not relevant.

[oroztocil]

Hi @mip1983, thanks for contacting us.

The error message tells us the browser expected a ~97 MB WebAssembly module but only received ~10 MB. A slow or lossy connection alone wouldn't normally cause this — browsers handle slow downloads fine and will wait for the full response. What this pattern typically indicates is that something in the serving pipeline is truncating or modifying the response bytestream before it reaches the browser (e.g., a reverse proxy, CDN, load balancer, or hosting platform imposing response size/timeout limits).

To help narrow this down, could you try the following?

1. Reproduce locally with the same publish output. Take the exact published output that's deployed to production and serve it locally (e.g., via nginx or IIS Express). If it loads fine locally, it would indicate that the problem is in the deployment/hosting infrastructure, not the app itself.
2. Deploy a minimal Blazor WebAssembly app to the same server configuration. Use the default template (dotnet new blazorwasm) and deploy it through the same pipeline/hosting setup. This could help identify whether the issue is specific to your app's asset size.

[dotnet-policy-service]

Hi @@mip1983. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.