Direct usage of WASI causing breakage during snapshot migration
MarkMcCaskey opened this issue · 4 comments
Hello, apologies if this isn't the correct place for this but I recently became aware of an issue involving this crate and the snapshot migration process:
Most of the WASI imports in a Wasm module come from the version of Rust being used (presumably from the stdlib or core), however crates using the wasi crate as a dependency, such as the getrandom crate cause specific versions of WASI imports to be included in the Wasm module. This puts those crates in a bit a strange state during snapshot migration because they have to choose which snapshot to support to be able to generate a valid WASI module.
This is an issue because it means they may have to choose, for example, between supporting nightly, stable, latest stable, or previous stable. Even if that weren't the case, every WASI snapshot requiring all dependent crates to update or break with the latest release isn't ideal either.
Unfortunately, I'm not familiar enough with Rustc or the nightly release process to have any suggestions for how this could be fixed.
Please let me know if I can help out with fixing this.
Most crates shouldn't be using the wasi crate's low-level APIs directly. In general, it's better to use the standard library APIs, which are easier, safer, and avoid this issue too.
Also, the eventual goal is to have the wasi crate provide a somewhat higher-level API which would be independent of the underlying WASI snapshot versions, which would give us more options. As WASI itself stablizes more, such an API should become more feasible.
getrandom is a little special, and it may admittedly have been a little premature to move it to depend on the wasi crate directly, but the infrastructure will improve, and this seems manageable for now.
rust-random/getrandom#126 specifically rust-random/getrandom@a056977 shows how a downstream crate might go about resolving this issue.
Essentially, your build toolchain and wasi runner have to be kept in sync. Using an new toolchain with an older runner (like wasmtime 0.3) will cause breakage (I would assume the reverse is also true, but I don't know).
That makes sense - the wasi runner component (wasi-common, for wasmtime and lucet) can't be compatible with newer versions of WASI than existed when it was created, but we are doing work to keep it compatible with older versions, so that runtimes can be upgraded without fear of breaking working code.
Lots of time has passed since this issue was opened and the landscape was changed quite a bit. WASI nowadays has explicit versions in interfaces which are used to coordinate functionality with guests and hosts. There's a clearer picture for upgrades given WASI's evolution story and how runtimes will support both old and newer versions.
Given all that, I'm going to close this as "probably no longer applicable".