Gareth (Mar 22 2024 at 12:52): Gareth (Mar 22 2024 at 12:52):I'm recently trying to upgrade from wasmtime-cli 17.0.0 (7201935fc 2023-12-14) to wasmtime-cli 20.0.0 (c6d923ae3 2024-03-21), the current Wasmtime main branch.
This includes upgrading my wasi-http from wasi:http@0.2.0-rc-2023-12-05 to wasi:http@0.2.0.
I have a simple get request function:
impl Request {
pub fn get(url: &str, headers: Option<HashMap<String, String>>) -> Result<Response> {
let (scheme, authority, path_with_query) = Request::parse_url(url)?;
let mut additional_headers: Vec<(String, Vec<u8>)> = vec![];
if let Some(add_headers) = headers {
for (key, value) in add_headers {
additional_headers.push((key, value.into_bytes()));
}
}
http::request(
Method::Get,
scheme,
authority.as_str(),
path_with_query.as_str(),
None,
Some(&additional_headers),
)
}
which utilizes https://github.com/bytecodealliance/wasmtime/blob/main/crates/test-programs/src/http.rs. I've taken a look and there appear to be virtually no changes to this file between versions.
However now when I make a get request, the code hangs here in http.rs with no errors returned:
let incoming_response = match future_response.get() {
Some(result) => result.map_err(|()| anyhow!("response already taken"))?,
None => {
let pollable = future_response.subscribe();
pollable.block();
future_response
.get()
.expect("incoming response available")
.map_err(|()| anyhow!("response already taken"))?
}
}?;
I am using wit-bindgen = { version = "0.18.0", default-features = false, features = ["realloc"] }
I have a pretty extensive test suite and all http requests are failing since upgrading my Wasmtime and wit file versions to current main, however can confirm that they all pass in the previous version. Any ideas on what could be causing this would be much appreciated?
Alex Crichton (Mar 22 2024 at 14:31):Would you be able to share an example to reproduce this perhaps?
Gareth (Mar 22 2024 at 16:55):Alex Crichton said:
Would you be able to share an example to reproduce this perhaps?
Sure Alex, here's an example that reproduces the issue : https://github.com/GarethEgerton/http_wasmtime
Alex Crichton (Mar 22 2024 at 19:34):@Gareth can you clarify what the failure mode for that looks like? Running that project with 17 and 19 the program doesn't hang for me
Gareth (Mar 22 2024 at 20:31):Alex Crichton said:
Gareth can you clarify what the failure mode for that looks like? Running that project with 17 and 19 the program doesn't hang for me
Oh really, did you run it from the wasmtime binary that was in my repo? I built this from wasmtime main using cargo build --features component-model,wasi-nn,wasi-http. I'm using cargo-component version 0.8.0, not sure if this has any effect.
The output I get when running is:
image.png
With no errors, just hangs here indefinitely.
I've just tried using wasmtime-v19.0.0-x86_64-linux.tar and this did run to completion, thanks :) I'm just wondering what would be the difference and why it didn't work when I compiled wasmtime myself?
Alex Crichton (Mar 22 2024 at 20:36):I didn't use the binary in the repo, no (sorry wasn't able to verify it was something I should run)
I used the wasmtime release binaries of 17/19 to test that
Alex Crichton (Mar 22 2024 at 20:36):and yeah it prints more after "Runs up to incoming_response and then hangs" for me
Alex Crichton (Mar 22 2024 at 20:37):you may want to try updating cargo-component? and/or wit-bindgen?
Alex Crichton (Mar 22 2024 at 20:37):I think there's been a few bug fixes which may affect this
Gareth (Mar 22 2024 at 20:43):Alex Crichton said:
I didn't use the binary in the repo, no (sorry wasn't able to verify it was something I should run)
I used the wasmtime release binaries of 17/19 to test that
That makes sense :) Have tried to run my full project with this v19 of wasmtime and the issue is that I need to use wasi-nn for onnx inference, so I think I need to compile wasmtime myself to include wasi-nn in the wasmtime binary.
I was using the example of onnx runtime with wasi-nn here as my basis https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-nn/examples/classification-component-onnx/Cargo.toml as a base, this uses wit-bindgen version 0.16.0, but up to 0.18.0 works for me. If I increase the wit bindgen version any higher, I get other errors:
error[E0599]: no function or associated item named into_handle found for struct Resource<_> in the current scope
--> src/bindings.rs:11963:38
|
11963 | wit_bindgen::rt::Resource::into_handle(self.handle)
| ^^^^^^^^^^^ function or associated item not found in Resource<_>
Alex Crichton (Mar 22 2024 at 20:44):ah yes, you'll need to compile from source to have onnx
Alex Crichton (Mar 22 2024 at 20:45):I think that may be a case where cargo-component is generating the bindings for you and it's getting out of sync with the wit-bindgen bindings perhaps?
Alex Crichton (Mar 22 2024 at 20:45):I'll admit though I don't know exactly what cargo-component does to manage src/bindings.rs for you
Gareth (Mar 22 2024 at 20:50):Yeah that makes sense that these could be out of sync... I also tried upgrading to latest cargo component 0.10.1 , with latest
wit-bindgen = { version = "0.22.0", default-features = false, features = ["realloc"] }
wit-bindgen-rt = "0.22.0"
When I try and compile I get this error:
error: failed to validate exported interface `wasi:cli/run@0.2.0`
Caused by:
module does not export required function `wasi:cli/run@0.2.0#run`
if you're running a command with a main function you'll want to remove [lib] in your Cargo.toml, rename src/lib.rs to src/main.rs, and add a fn main() {}
Alex Crichton (Mar 22 2024 at 20:56):oh sorry, no disregard that
Alex Crichton (Mar 22 2024 at 20:56):well, what you're doing right now is an alternative to all of that
Alex Crichton (Mar 22 2024 at 20:57):with the new version of wit-bindgen you'll need to do export!(Component);
Alex Crichton (Mar 22 2024 at 20:57):or some macro name, I forget the exact name
Peter Huene (Mar 22 2024 at 21:09):Please see the release notes for breaking changes: https://github.com/bytecodealliance/cargo-component/releases/tag/v0.9.0 (there's no breaking changes in 0.10.0)
Gareth (Mar 22 2024 at 21:24):Alex Crichton said:
with the new version of wit-bindgen you'll need to do
export!(Component);
Thanks both for the help :) It looks like this is what I need to implement,
Added bindings::export!(Component with_types_in bindings); and this builds now.
Peter Huene (Mar 22 2024 at 21:36):you should also no longer need the dep on wit-bindgen (but will need the replacement wit-bindgen-rt)
Gareth (Mar 22 2024 at 21:38):Thanks, this also builds. However I do still have the issue of the http request hanging when I am building Wasmtime myself. But it works when using prebuilt Wasmtime v19.
Gareth (Mar 24 2024 at 11:20):Thanks again for the help.
I've been trying further to fix the issue of the http request hanging. As mentioned, when I use v19 Wasmtime compiled here wasmtime-v19.0.0-x86_64-linux.tar, I can run this project https://github.com/GarethEgerton/http_wasmtime and the http get request completes. However when I compile Wasmtime from source, the current main branch, and I've also tried release https://github.com/bytecodealliance/wasmtime/tree/v19.0.0, my own compiled Wasmtime (which i need for wasi-nn) still has the http request hang.
I'm wondering if I am not compiling this correctly. The command I am using is cargo build --features component-model,wasi-nn,wasi-http from Wasmtime repo. Can you confirm if this is correct?
Then to run my wasm module: ./bin/wasmtime run --wasi http --wasm component-model target/wasm32-wasi/debug/http_test.wasm
To clarify, I am now using the latest version of cargo component 0.10.1 and wit-bindgen-rt = "0.22.0"
Alex Crichton (Mar 24 2024 at 18:54):Apologies I should have checked main when I only checked the 19.0.0 release. I believe you've found a bug in a recent commit to main which I've posted a fix for at https://github.com/bytecodealliance/wasmtime/pull/8229
Gareth (Mar 25 2024 at 20:12):Great, thanks Alex, was able to upgrade and everything is working now :)
Last updated: Dec 23 2024 at 12:05 UTC