Console warning in dotnet workloads

[camillobruni]

When running dotnet-aot-wasm and dotnet-interp-wasm I see 2 console warnings:
MONO_WASM: WebAssembly resource does not have the expected content type "application/wasm", so falling back to slower ArrayBuffer instantiation.

It would be nice to try to avoid them.

[danleh]

I investigated this a bit, and I think this is an error inside .NET / Blazor, not our server setup.

My understanding is that dotnet manages / parallelizes resource downloads with some kind of download manager, I believe the source for that is https://github.com/dotnet/runtime/blob/2a6bd3a53cd8476f440b1a0dc3b0776f24f5494b/src/mono/wasm/runtime/loader/assets.ts#L453. The string Throttling further parallel downloads in that line also appears in our build artifact (search for the string in https://github.com/WebKit/JetStream/blob/main/wasm/dotnet/build-aot/wwwroot/_framework/dotnet.js).

In JetStream, you can set a breakpoint on the warning WebAssembly resource does not have the expected content type "application/wasm", so falling back to slower ArrayBuffer instantiation in DevTools when running without preloading https://webkit-jetstream-preview.netlify.app/?test=dotnet-aot-wasm&prefetchResources=false&startAutomatically=true

Then follow the execution backwards until the following snippet (I formatted it, originally it's minified):

async function pe(e) {
    for (; G; )
        await G.promise;
    try {
        ++H,
        H == qe.maxParallelDownloads && (qe.diagnosticTracing && h("Throttling further parallel downloads"),
        G = r());
        const t = await async function(e) {
            if (e.pendingDownload && (e.pendingDownloadInternal = e.pendingDownload),
            e.pendingDownloadInternal && e.pendingDownloadInternal.response)
                return e.pendingDownloadInternal.response;
            if (e.buffer) {
                const t = await e.buffer;
                return e.resolvedUrl || (e.resolvedUrl = "undefined://" + e.name),
                e.pendingDownloadInternal = {
                    url: e.resolvedUrl,
                    name: e.name,
                    response: Promise.resolve({     // <-- This is a mock response object of sorts...
                        ok: !0,
                        arrayBuffer: () => t,
                        json: () => JSON.parse(new TextDecoder("utf-8").decode(t)),
                        text: () => {
                            throw new Error("NotImplementedException")
                        }
                        ,
                        headers: {
                            get: () => {}
                        }
                    })
                },
                e.pendingDownloadInternal.response
            }
...

IIUC, this creates a new Promise with a "mock" Response, but the headers are actually empty, such that later this guard triggers:

                const e = le("dotnetwasm");
                await he(e),
                e && e.pendingDownloadInternal && e.pendingDownloadInternal.response || Ke(!1, "Can't load dotnet.native.wasm");
                const t = await e.pendingDownloadInternal.response
                  , o = t.headers && t.headers.get ? t.headers.get("Content-Type") : void 0;
                let n;
                if ("function" == typeof WebAssembly.compileStreaming && "application/wasm" === o)
                    n = await WebAssembly.compileStreaming(t);
                else {
-->                 We && "application/wasm" !== o && w('WebAssembly resource does not have the expected content type "application/wasm", so falling back to slower ArrayBuffer instantiation.');
                    const e = await t.arrayBuffer();
                    qe.diagnosticTracing && h("instantiate_wasm_module buffered"),
                    n = Be ? await Promise.resolve(new WebAssembly.Module(e)) : await WebAssembly.compile(e)
                }

since o is actually t.headers.get("Content-Type"), where t is this mock object with empty headers, and so o is undefined.

I think this needs someone from Microsoft / .NET / Blazor to assist, hence adding @maraf and @pavelsavara. Concrete questions:

1. Does Blazor use some "download manager" to parallelize resource downloads? Can this be disabled?
2. Is my understanding of this mock response object correct? In particular, is it intended that no headers, particularly no Content-Type is set?
3. Given this, Blazor can never use streaming Wasm instantiation with that download manager, is that right?

[pavelsavara]

This is because the config is given asset.buffer in

JetStream/wasm/dotnet/benchmark.js

Line 22 in 1dbb861

buffer: await JetStream.getBinary(JetStream.preload.wasmBinaryUrl),

and that could be another binary type than WASM, perhaps DLL. This API is not able to tell the difference.

Instead we could do

{
    name: "dotnet.native.wasm",
    resolvedUrl:  JetStream.preload.wasmBinaryUrl,
    behavior: "dotnetwasm",
    pendingDownload: {
        name: "dotnet.native.wasm",
        url: JetStream.preload.wasmBinaryUrl,
        response: JetStream.getBinary(JetStream.preload.wasmBinaryUrl),
    }
},

I have not tested this right now, let me know if it worked.
Maybe you need something that return (unresolved) Promise<Response> not JetStream.getBinary

Regarding throttling and download retry, we have it there because we are testing on some under-powered devices. Chrome can throw net::ERR_INSUFFICIENT_RESOURCES if you start too many fetch at the same time.

You can disable throttling by setting

{
    maxParallelDownloads: 10000,
    enableDownloadRetry: false,
}

The config schema is https://github.com/dotnet/runtime/blob/v10.0.0/src/mono/browser/runtime/dotnet.d.ts#L138

[pavelsavara]

1. Does Blazor use some "download manager" to parallelize resource downloads? Can this be disabled?

Yes, there is bespoke JS code in the dotnet loader.

2. Is my understanding of this mock response object correct? In particular, is it intended that no headers, particularly no `Content-Type` is set?

We could improve that in the future releases. We would have to guess it based on behavior field of that config.

3. Given this, Blazor can never use streaming Wasm instantiation with that download manager, is that right?

We use streaming compilation in Net10 and below (with right HTTP headers). We will use streaming instantiation Net11 or Net12, there is refactoring in progress which improves that.