Files
rose-ash/plans/NOTE-wasm-try-deprecation.md
giles 7d07ac7e4a
Some checks failed
Test, Build, and Deploy / test-build-deploy (push) Failing after 43s
note: rebuild does NOT fix the WASM 'try' deprecation (tested) — needs toolchain upgrade
Ran build-all.sh with wasm_of_ocaml 6.3.2: output .wasm units came out byte-identical to
the Jun-29 backup (same hashes, diff -rq clean), so 6.3.2 still emits legacy 'try'. A plain
rebuild is a dead end; the fix needs a newer wasm_of_ocaml (or flag) that emits try_table.
No harm done — deployed artifacts unchanged, live SPA intact. apt wabt/wasm2wat can't read
these wasm-GC binaries (0x5e); need wasm-tools or a real-browser check.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-30 15:51:44 +00:00

43 lines
2.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Follow-up: WASM kernel uses deprecated `try` exception instruction (+ sync XHR)
**Found:** 2026-06-30, from a real browser console on `blog.rose-ash.com` (modern Chrome/Firefox).
**Severity:** not yet breaking — *deprecation warnings*. The SPA still boots (a hard refresh
cleared a stale cached loader, which was the day's actual symptom). But when browsers **remove**
the legacy `try` instruction, the WASM kernel will fail to instantiate → "SxKernel not found
after 5s" → no SPA (server-rendered pages + native-form writes still work; only SPA nav + the
interactive picker need the kernel).
## The two warnings
1. **`WebAssembly exception handling 'try' instruction is deprecated … use 'try_table' instead`**
(×6). The kernel `shared/static/wasm/sx_browser.bc.wasm.assets/*.wasm` was compiled (Jun-29
artifact) with the legacy exception-handling encoding. wasm_of_ocaml standardized on
`try_table`; current toolchain is **6.3.2**.
2. **`Synchronous XMLHttpRequest on the main thread is deprecated`** — `sx-platform.js:575`,
`loadManifest()` does `xhr.open("GET", …module-manifest.sx…, false)` (sync). Browsers
increasingly restrict sync XHR.
## Fix
1. **A plain rebuild does NOT fix it — TESTED 2026-06-30, dead end.** Ran
`bash hosts/ocaml/browser/build-all.sh` with the current `wasm_of_ocaml 6.3.2`. The output
`.wasm` units came out **byte-identical** to the Jun-29 backup (same content hashes, e.g.
`dune__exe__Sx_browser-4878f9e1.wasm`; `diff -rq` clean). So 6.3.2 still emits the legacy
`try` — rebuilding gains nothing. **The fix needs a newer `wasm_of_ocaml` (or a flag) that
emits `try_table`** — a toolchain *upgrade* (`opam upgrade wasm_of_ocaml-compiler` to a
version that defaults to `try_table`, or find the relevant `--enable` flag), then rebuild +
verify. (Disassembly check note: apt's `wasm2wat`/wabt is too old for these wasm-GC binaries —
`error: unexpected type form (got 0x5e)`; need `wasm-tools` for wasm-GC, or verify in a real
up-to-date browser. Playwright's older chromium still accepts `try`, so it won't tell you.)
2. **`loadManifest` → async.** Change to an async fetch and restructure the boot so the manifest
is awaited before module loading (it's currently consumed synchronously). Contained to
`hosts/ocaml/browser/sx-platform.js` + its copy in `shared/static/wasm/`.
## Scope / ownership
`hosts/ocaml/browser/` is the OCaml→WASM toolchain — generally out of the host loop's lane, though
the host loop has committed there for the blog SPA (b21ae05e, 689dae7d). A kernel rebuild affects
the LIVE SPA, so do it when the box is quiet, with real-browser verification, and a quick rollback
path (the Jun-29 `.assets` are the known-good artifact — keep a copy before overwriting). Not
urgent; schedule rather than rush.