dx asset bundling silently fails under wasm-threads rustflags (follow-up to #5079, still reproduces on dx 0.7.9)

[uditrugman]

Summary

On dx 0.7.9, dx build --platform web fails to bundle and patch asset!() records when the wasm-threads rustflags (the same set used by wasm-bindgen-rayon and cpal's audioworklet backend) are present. PR #5163 and PR #5189 were the previous round of fixes for this class of bug (#5079, #5188) and they're both in 0.7.9, but the warnings from #5188 still appear and the public/assets/ directory ends up empty.

Reproducer

Minimal isolated repro: https://github.com/uditrugman/dx-wasm-threads-asset-repro

• One dioxus web app, main.rs has one asset!() call.
• One asset: assets/style.css (~30 bytes).
• .cargo/config.toml with the wasm-threads rustflags from Some linker args (atomics & bulk-memory) breaks assets #5079.
• No cpal, no rayon, no threads spawned, no other crates. Just dioxus = "0.7.9".

With the rustflags

$ dx build --platform web
…
WARN Failed to deserialize as BundledAsset. Data length: 4096,
     first 32 bytes: [119, 97, 115, 109, 45, 116, 104, 114, 101, 97,
     100, 115, 45, 97, 115, 115, 101, 116, 45, 114, 101, 112, 114,
     111, 47, 97, 115, 115, 101, 116, 115, 47]
WARN Found a symbol at offset 4213283 that could not be deserialized.
     This may be caused by a mismatch between your dioxus and
     dioxus-cli versions, or the symbol may be in an unsupported format.
WARN Found a symbol at offset 4217379 that could not be deserialized.
     …
INFO Running wasm-bindgen...
INFO Client build completed successfully!

• The byte pattern decodes to "wasm-threads-asset-repro/assets/" — that's literally the asset path. dx finds the right offset but can't deserialize the record.
• target/dx/.../public/assets/ is empty.
• 3 unpatched "This should be replaced by dx..." placeholder strings remain in the wasm.

Same source without the rustflags

$ mv .cargo/config.toml .cargo/config.toml.bak && rm -rf target/dx
$ dx build --platform web
…
INFO Copying asset (1/1): /…/assets/style.css
INFO Client build completed successfully!

$ ls target/dx/.../public/assets/
style-dxh869c7541c5a361e.css

Works exactly as expected.

Versions

• dx --version → dioxus 0.7.9 (bfcc111)
• dioxus = "0.7.9" (matches dx)
• All manganis*, dioxus-cli-config, dioxus-core, dioxus-web = 0.7.9
• nightly Rust, rust-src component installed.

manganis-core 0.7.9 intentionally pulls both const-serialize 0.7.2 and 0.8.0-alpha.0 (with the 0.8 having a const-serialize-07 feature for read-side backcompat). The "mismatch between your dioxus and dioxus-cli versions" warning's first half doesn't apply.

What's not the cause (ruled out in the repro)

• Extra rustflags vs the original Some linker args (atomics & bulk-memory) breaks assets #5079 setup (+mutable-globals, --export=__heap_base). Removing both → identical warnings.
• Debug symbols. --debug-symbols=false → identical warnings.
• Inject loading scripts. --inject-loading-scripts=false → still empty public/assets/.
• A cpal or rayon-specific issue. The repro has neither.

Hypothesis

The rustflags (probably --shared-memory + --import-memory + the TLS exports together with -Z build-std=std,panic_abort so std is rebuilt with +atomics/+bulk-memory) change the wasm data-section layout in a way find_wasm_symbol_offsets doesn't account for. dx does locate the candidate offset (the byte preview proves the asset record is found), but the structured deserialization fails — beyond what PR #5163 added.

Happy to do more digging into the wasm-side encoding if it'd help.

[uditrugman]

Bisected the rustflags down to the minimum trigger — pushed to the reproducer repo (commit 5ff3f85). It's much narrower than the original #5079 set:

.cargo/config.toml	Asset bundling
+atomics alone (no -Z build-std)	works
+bulk-memory alone + -Z build-std	works
+atomics + -Z build-std	broken
+atomics,+bulk-memory + -Z build-std	broken
Full wasm-threads set (TLS exports, --shared-memory, etc.)	broken

So the trigger is std rebuilt with +atomics — not the linker flags, not +bulk-memory, not the TLS exports. User-code +atomics alone (linked against the precompiled std) doesn't change the wasm enough to break the scanner; the rebuilt std with atomic ops in it does.

The current .cargo/config.toml in the reproducer is now just:

[target.wasm32-unknown-unknown]
rustflags = ["-C", "target-feature=+atomics"]

[unstable]
build-std = ["panic_abort", "std"]

Reproduces with one asset!(), one dioxus = "0.7.9" dep, and that config.

[uditrugman]

One more data point: I also tested the original #5079 reporter's exact reproducer (https://github.com/wheregmis/rustflags_dioxus) against released dioxus 0.7.9 + dx 0.7.9 — just swapped their pinned git = "wheregmis/dioxus" branch = "fix_atomics_assets" for version = "0.7.9".

It reproduces the bug identically:

WARN Failed to deserialize as BundledAsset. Data length: 4096,
     first 32 bytes: [47, 116, 109, 112, 47, 114, 117, 115, 116, 102, 108, 97, 103, 115, 95,
                      100, 105, 111, 120, 117, 115, 47, 97, 115, 115, 101, 116, 115, 47, 109, 97, 105]
     # ascii: "/tmp/rustflags_dioxus/assets/mai..." — main.css's absolute path

So PR #5163's fix doesn't cover the original wasm-bindgen-rayon reproducer it was supposed to fix either — same failure mode. The fix may have targeted a narrower passive-segment edge case than the general +atomics-rebuilt-std issue, or a regression has since landed.

(The reporter's repro pinned their own dioxus fork branch from Dec 2025, which is why they probably didn't notice the released crate is still broken.)

[uditrugman]

Update: PR #5163 never actually fixed asset bundling — it only made the scanner try (and silently fail).

I verified by installing dx 0.7.3 (first release containing PR #5163, cut 10 days after merge) and running both reproducers against it:

Setup	dx version	Outcome
dx-wasm-threads-asset-repro (minimal)	0.7.3	WARN "Found an asset … could not be deserialized" ×2 — public/assets/ empty, 3 unpatched placeholders
wheregmis/rustflags_dioxus + the fix_atomics_assets fork branch they pinned	0.7.3	WARN ×3 — public/assets/ empty, 3 unpatched placeholders
Same minimal repro	0.7.9	WARN ×many — public/assets/ empty, 3 unpatched placeholders

The only difference between versions is how chatty the scanner is — 0.7.3 quietly logs a few candidate misses, 0.7.9 logs every false-positive offset. Neither version actually extracts the assets.

So the comment on PR #5163 ("Just tested and It worked. Thank you. 🎉") was, in retrospect, a false-positive verification — the build completed without errors, so it looked fixed, but the resulting page would have served 404s for every asset!() URL. No one seems to have caught it because:

• The reporter's repo still pins their pre-merge fork branch (didn't track main)
• Build output isn't an error, just warnings
• You only notice browser-side when CSS/images don't load

That makes this likely a regression detection problem, not a hard bug to fix — the deserialize path that succeeded in dev never made it to release. Might be worth a regression test that asserts public/assets/ is non-empty when assets are declared.

[uditrugman]

Cross-platform / cross-version CI bisect. Added a GitHub Actions workflow to the reproducer that matrix-tests 5 rustc nightly dates × 3 dioxus versions on Linux x86_64. Source: `.github/workflows/bisect.yml`. Run results — all 8 jobs pass and all 8 reproduce the bug identically:

rustc	dioxus + dx	Build	Assets bundled	"could not be deserialized" warnings
nightly (latest)	0.7.9	✅	0	3
nightly-2026-04-01	0.7.9	✅	0	3
nightly-2026-02-01	0.7.9	✅	0	3
nightly-2025-12-15	0.7.9	✅	0	3
nightly-2025-10-01	0.7.9	✅	0	3
nightly (latest)	0.7.7	✅	0	3
nightly (latest)	0.7.3	✅	0	2
nightly-2025-12-15	0.7.3	✅	0	2

That rules out:

• Host OS / arch — my local is aarch64 macOS, CI is x86_64 Linux. Identical outcome.
• rustc nightly snapshot — five different dates, identical outcome.
• dioxus / dx version — three different released versions (0.7.3 / 0.7.7 / 0.7.9), identical outcome. dx 0.7.3 just emits fewer false-positive warnings because the scanner was less aggressive there; the actual asset extraction has never worked.

So the bug isn't a regression and isn't environmental — it has been silently present in every released dx that claims to handle the wasm-threads case. The workflow can serve as a regression test once a fix lands (Files in public/assets/ should be > 0).