BUG: Production Namadillo build breaks multicore features

[jurevans]

When we deploy a production build of Namadillo (for example, to https://namada-interface-dev.netlify.app/ which is where I first noticed this), features such as Shielded Sync do not work (In both Chrome & Firefox based browsers). The workerHelpers.js scripts seem to fail to load only when it's a production build, for whatever reason. A single core Wasm/SDK build works just fine on production.

See section on Vite at: wasm-bindgen-rayon

NOTE May relate to something not being configured according to https://github.com/RReverser/wasm-bindgen-rayon (see Vite section)

Steps to reproduce

• In Namadillo:
  • yarn wasm:build:multicore && yarn build:only, or:
  • Update yarn build to run the yarn wasm:build:multicore script (instead of simply yarn wasm:build), then run yarn build
• cd dist
• python -m http.server or host with any local web server (Note: React-Router kinda breaks if you attempt to go directly to a sub-route, but navigating around from the base path will be fine!)
• Navigate to http://localhost:8000
• Attempt to sync

What I'm observing is that the production version of the shielded web workers aren't executing properly. File seems to load fine:

"GET /assets/workerHelpers.worker-DihhFSsk.js HTTP/1.1" 304

Not sure if it's related, but in the Network tab, these appear to remain as Pending. Navigating directly to the script and it loads in a browser. Perhaps it's simply packaged in a way that causes it to fail?

Since multicore will be crucial to enabling MASP features, this should be resolved by Phase 3.

NOTES

I ran a test where I built @namada/shared in Multicore in development mode, and this produced the same issue when Namadillo was built in production mode. The issue seems to be on the Namadillo side. Running a local dev Namadillo with a "release" Multicore wasm build works.

This issue seems to be related to the workerHelper.worker.js scripts spawned by Rayon. Note the difference in how these are requested on dev versus production modes:

Production Mode

(in dist)

# In dist/
python -m http.server

# In Network tab (Chrome)
http://localhost:8000/assets/workerHelpers.worker-DihhFSsk.js

Development Mode

# In namadillo/
yarn dev

# In Network tab (Chrome)
http://localhost:5173/@fs/home/user/dev/namada-interface/packages/shared/src/shared/snippets/wasm-bindgen-rayon-e6698bae2cc7187f/src/workerHelpers.worker.js?worker_file&type=module

There are significant differences in the contents of these files due to the build process, so perhaps there is something breaking when built for production during bundling & minification.

[mateuszjasiuk]

After some investigation it turned out that server has to set specific response headers for workers to work properly:

from http.server import HTTPServer, SimpleHTTPRequestHandler
import os

class CustomHandler(SimpleHTTPRequestHandler):
    def end_headers(self):
        # Add the cross-origin headers to every response
        self.send_header("Cross-Origin-Opener-Policy", "same-origin")
        self.send_header("Cross-Origin-Embedder-Policy", "require-corp")

        # Call the base class's end_headers method
        super().end_headers()

# Run the server
server_address = ("", 8000)
httpd = HTTPServer(server_address, CustomHandler)
print("Serving on http://localhost:8000/")
httpd.serve_forever()