`wasm-pack build --release` intermittently fails with `[parse exception: Only 1 table definition allowed in MVP]`

[Madoshakalaka]

🐛 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: 1

Might 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-opt from PATH so wasm-pack used 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) via rustup install 1.95.0 (same build hash as CI).
• wasm-pack 0.14.0, which pulled wasm-bindgen 0.2.117 CLI 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-struct at commit 28219ae1 in yewstack/yew (the same commit as the most recent CI failure).
• cargo clean between every run to force a full recompile. Also tried RAYON_NUM_THREADS=4 to 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: c082ed05f4cd90f29436fb8d4d54b4f101383c035565d755059cb65dbfd5c6b0

Bit-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/wasm-pack-action@v0.4.0)
• rustc version: 1.95.0 (59807616e 2026-04-14), via dtolnay/rust-toolchain@master with toolchain: 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 found on 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=4 also reproduces the success deterministically.