`wasm-pack build --release` intermittently fails with `[parse exception: Only 1 table definition allowed in MVP]`
Bug description
wasm-pack build --release intermittently fails on CI with:
[parse exception: Only 1 table definition allowed in MVP (at 0:6496)]
Fatal: error in parsing input
Error: failed to execute `wasm-opt`: exited with exit code: 1Might have the same underlying cause of #793 because of the similar error messages. The same commit on the same pinned toolchain alternates between pass and fail across runs. Identical inputs produce different outcomes on GitHub Actions' ubuntu-latest.
Concrete evidence from the yew repo's benchmark workflow (all runs: wasm-pack 0.14.0, rustc 1.95.0 commit 59807616e 2026-04-14, wasm-bindgen 0.2.117, bundled binaryen version_117, ubuntu-latest, CARGO_INCREMENTAL=0, No cache found reported by Swatinem/rust-cache@v2):
| Run | Commit | Result |
|---|---|---|
| https://github.com/yewstack/yew/actions/runs/24621224084/job/71992139312 | e163df06 |
pass |
| https://github.com/yewstack/yew/actions/runs/24637634315/attempts/1 | a259eae6 |
fail |
| https://github.com/yewstack/yew/actions/runs/24637634315/job/72037123240 | a259eae6 (retry) |
pass |
| https://github.com/yewstack/yew/actions/runs/24648941217/attempts/1 | 28219ae1 |
fail |
| https://github.com/yewstack/yew/actions/runs/24648941217/job/72078898638 | 28219ae1 (retry) |
pass |
Both retries of failing runs hit the same "No cache found" state as the original attempt, so cache state does not explain the difference. Cargo.lock is unchanged across all runs. The only two reliable signals so far are: (1) failures happen; (2) rerunning the exact same job frequently passes.
Steps to reproduce
I was unable to reproduce the failure on my machine. Setup used:
- Hid
/usr/bin/wasm-optfromPATHsowasm-packused its bundled binaryen 117 (matching CI; confirmed via~/.cache/.wasm-pack/wasm-opt-*/bin/wasm-opt --version=version 117 (version_117)). rustc 1.95.0 (59807616e 2026-04-14)viarustup install 1.95.0(same build hash as CI).wasm-pack 0.14.0, which pulledwasm-bindgen 0.2.117CLI into its cache.- Exact command used by the failing CI step:
RUSTFLAGS='--cfg getrandom_backend="wasm_js"' wasm-pack build --release --target web --no-typescript --out-name js-framework-benchmark-yew --out-dir /tmp/bundled-dist - Target:
tools/benchmark-structat commit28219ae1inyewstack/yew(the same commit as the most recent CI failure). cargo cleanbetween every run to force a full recompile. Also triedRAYON_NUM_THREADS=4to match the CI vCPU count.
Observed across 5 clean rebuilds:
Run 1 hash: c082ed05f4cd90f29436fb8d4d54b4f101383c035565d755059cb65dbfd5c6b0
Run 2 hash: c082ed05f4cd90f29436fb8d4d54b4f101383c035565d755059cb65dbfd5c6b0
Run 3 hash: c082ed05f4cd90f29436fb8d4d54b4f101383c035565d755059cb65dbfd5c6b0
Run 4 hash: c082ed05f4cd90f29436fb8d4d54b4f101383c035565d755059cb65dbfd5c6b0
Run 5 hash: c082ed05f4cd90f29436fb8d4d54b4f101383c035565d755059cb65dbfd5c6b0Bit-identical output every run. The wasm has two tables (funcref + __wbindgen_externrefs externref) and a target_features custom section correctly listing reference-types. wasm-opt 117 --print-features reads the section and reports --enable-reference-types. Running wasm-opt 117 -O4 directly on the pre-opt binary succeeds.
So locally, the binaryen auto-detection path works and the wasm-bindgen output is deterministic. Something specific to the GitHub Actions environment tips it into the failing branch.
Your environment
Failing environment (yew CI):
- wasm-pack version: 0.14.0 (installed via
jetli/[email protected]) - rustc version: 1.95.0 (59807616e 2026-04-14), via
dtolnay/rust-toolchain@masterwithtoolchain: stable - wasm-bindgen version: 0.2.117 (both library and CLI)
- binaryen: version_117 (bundled by wasm-pack)
- Runner:
ubuntu-latest(4 vCPUs, 16 GB RAM) - Cache:
Swatinem/rust-cache@v2,No cache foundon the failing runs CARGO_INCREMENTAL=0
Non-reproducing environment (local):
- Same
wasm-pack,rustc 1.95.0,wasm-bindgen 0.2.117, binaryen 117 as CI. - Arch Linux 6.18.21-1-lts, AMD Ryzen 9 5950X (16 cores / 32 threads).
RAYON_NUM_THREADS=4also reproduces the success deterministically.
Source: wasm-bindgen/wasm-pack