Stream: git-wasmtime

Topic: wasmtime / issue #12385 Using `component-model-async` => ...

Wasmtime GitHub notifications bot (Jan 21 2026 at 21:44):

ignatz edited issue #12385:

For context, I found https://github.com/bytecodealliance/wasmtime/issues/12154 which had the same error message but supposedly it's fixed, it may also be unrelated...

...anyway, I'm using wasmtime v41.0.0 enabling the "component-model-async" feature, while still using WASIp2.

The host seems to be happy, but when I build the WASM guest, I'm getting:

cargo build --target wasm32-wasip2 --release
   Compiling wasm-rust-guest-testfixture v0.0.0 (/home/sebastian/projects/trailbase/client/testfixture/guests/rust)
error: linking with `wasm-component-ld` failed: exit status: 1
  |
  = note:  "wasm-component-ld" "-flavor" "wasm" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "cabi_post_trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "wasi:http/incoming-handler@0.2.9#handle" "--export" "cabi_realloc" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<431 object files omitted>" "/tmp/rustcvjZFo1/{libwit_bindgen-82480354a7f0311d,libwit_bindgen-07ccf6eb5537f8e1}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/libcompiler_builtins-*.rlib" "-L" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/build/wit-bindgen-8ffd3c9ddbea9b25/out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained" "-o" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/deps/wasm_rust_guest_testfixture.wasm" "--gc-sections" "--no-entry" "-O3" "--strip-debug"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: error: failed to parse core wasm for componentization

          Caused by:
              0: decoding custom section component-type:wit-bindgen:0.51.0:trailbase:component@0.1.0:interfaces-with-all-of-its-exports-removed:encoded world
              1: invalid leading byte (0x43) for component defined type (at offset 0x2a38)

When I build with --target wasm-unknown-unknown or --target wasm-wasip1, the component builds but the guest is not able to load it: "Wasmtime: failed to parse WebAssembly module".

The wasm-wasip3 target seems to be retired? Anyway, which would be the right one? Am I holding something else wrong? For example, does component-model-async require me to also switch to WASIp3 in lock-step?

Much appreciated :folded_hands:

Wasmtime GitHub notifications bot (Jan 21 2026 at 21:45):

ignatz edited issue #12385:

For context, I found https://github.com/bytecodealliance/wasmtime/issues/12154 which had the same error message but supposedly it's fixed, it may also be unrelated...

...anyway, I'm using wasmtime v41.0.0 enabling the "component-model-async" feature, while still using WASIp2.

The host seems to be happy, but when I build the WASM guest, I'm getting:

cargo build --target wasm32-wasip2 --release
   Compiling wasm-rust-guest-testfixture v0.0.0 (/home/sebastian/projects/trailbase/client/testfixture/guests/rust)
error: linking with `wasm-component-ld` failed: exit status: 1
  |
  = note:  "wasm-component-ld" "-flavor" "wasm" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "cabi_post_trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "wasi:http/incoming-handler@0.2.9#handle" "--export" "cabi_realloc" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<431 object files omitted>" "/tmp/rustcvjZFo1/{libwit_bindgen-82480354a7f0311d,libwit_bindgen-07ccf6eb5537f8e1}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/libcompiler_builtins-*.rlib" "-L" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/build/wit-bindgen-8ffd3c9ddbea9b25/out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained" "-o" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/deps/wasm_rust_guest_testfixture.wasm" "--gc-sections" "--no-entry" "-O3" "--strip-debug"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: error: failed to parse core wasm for componentization

          Caused by:
              0: decoding custom section component-type:wit-bindgen:0.51.0:trailbase:component@0.1.0:interfaces-with-all-of-its-exports-removed:encoded world
              1: invalid leading byte (0x43) for component defined type (at offset 0x2a38)

When I build with --target wasm-unknown-unknown or --target wasm-wasip1, the component builds but the host is no longer able to load it: "Wasmtime: failed to parse WebAssembly module".

The wasm-wasip3 target seems to be retired? Anyway, which would be the right one? Am I holding something else wrong? For example, does component-model-async require me to also switch to WASIp3 in lock-step?

Much appreciated :folded_hands:

Wasmtime GitHub notifications bot (Jan 21 2026 at 21:45):

ignatz edited issue #12385:

For context, I found https://github.com/bytecodealliance/wasmtime/issues/12154 which had the same error message but supposedly it's fixed, it may also be unrelated...

...anyway, I'm using wasmtime v41.0.0 enabling the "component-model-async" feature, while still using WASIp2.

The host seems to be happy, but when I build the WASM guest, I'm getting:

cargo build --target wasm32-wasip2 --release
   Compiling wasm-rust-guest-testfixture v0.0.0 (/home/sebastian/projects/trailbase/client/testfixture/guests/rust)
error: linking with `wasm-component-ld` failed: exit status: 1
  |
  = note:  "wasm-component-ld" "-flavor" "wasm" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "cabi_post_trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "wasi:http/incoming-handler@0.2.9#handle" "--export" "cabi_realloc" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<431 object files omitted>" "/tmp/rustcvjZFo1/{libwit_bindgen-82480354a7f0311d,libwit_bindgen-07ccf6eb5537f8e1}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/libcompiler_builtins-*.rlib" "-L" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/build/wit-bindgen-8ffd3c9ddbea9b25/out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained" "-o" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/deps/wasm_rust_guest_testfixture.wasm" "--gc-sections" "--no-entry" "-O3" "--strip-debug"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: error: failed to parse core wasm for componentization

          Caused by:
              0: decoding custom section component-type:wit-bindgen:0.51.0:trailbase:component@0.1.0:interfaces-with-all-of-its-exports-removed:encoded world
              1: invalid leading byte (0x43) for component defined type (at offset 0x2a38)

When I build with --target wasm-unknown-unknown or --target wasm-wasip1, the component builds but the host is no longer able to load it: "Wasmtime: failed to parse WebAssembly module".

The wasm-wasip3 target seems to be retired? Anyway, which target is the right one yo use? Am I holding something else wrong? For example, does component-model-async require me to also switch to WASIp3 in lock-step?

Much appreciated :folded_hands:

Wasmtime GitHub notifications bot (Jan 21 2026 at 21:48):

ignatz edited issue #12385:

For context, I found https://github.com/bytecodealliance/wasmtime/issues/12154 which had the same error message but supposedly it's fixed, it may also be unrelated...

...anyway, I'm using wasmtime v41.0.0 enabling the "component-model-async" feature, while still using WASIp2.

The host seems to be happy, but when I build the WASM guest, I'm getting:

cargo build --target wasm32-wasip2 --release
   Compiling wasm-rust-guest-testfixture v0.0.0 (/home/sebastian/projects/trailbase/client/testfixture/guests/rust)
error: linking with `wasm-component-ld` failed: exit status: 1
  |
  = note:  "wasm-component-ld" "-flavor" "wasm" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "cabi_post_trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "wasi:http/incoming-handler@0.2.9#handle" "--export" "cabi_realloc" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<431 object files omitted>" "/tmp/rustcvjZFo1/{libwit_bindgen-82480354a7f0311d,libwit_bindgen-07ccf6eb5537f8e1}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/libcompiler_builtins-*.rlib" "-L" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/build/wit-bindgen-8ffd3c9ddbea9b25/out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained" "-o" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/deps/wasm_rust_guest_testfixture.wasm" "--gc-sections" "--no-entry" "-O3" "--strip-debug"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: error: failed to parse core wasm for componentization

          Caused by:
              0: decoding custom section component-type:wit-bindgen:0.51.0:trailbase:component@0.1.0:interfaces-with-all-of-its-exports-removed:encoded world
              1: invalid leading byte (0x43) for component defined type (at offset 0x2a38)

When I build with --target wasm-unknown-unknown or --target wasm-wasip1, the component builds but the host is no longer able to load it: "Wasmtime: failed to parse WebAssembly module".

The wasm-wasip3 target seems to be retired? Anyway, which target is the right one to use? Am I holding something else wrong? For example, does component-model-async require me to also switch to WASIp3 in lock-step?

Much appreciated :folded_hands:

Wasmtime GitHub notifications bot (Jan 21 2026 at 22:07):

alexcrichton commented on issue #12385:

Thanks for the report! The issue here is that your wasm-component-ld is too old and doesn't understand the things that a modern wit-bindgen is inserting. You can fix that by using beta/nightly Rust for example and waiting for those changes to ride their way to stable.

The wasm-wasip3 target seems to be retired?

Oh not retired, just not created yet. The wasm32-wasip3 target isn't shipped in rustup at this time.

Anyway, which target is the right one to use?

wasm32-wasip2 is suitable for now

Am I holding something else wrong?

Nope! Just a toolling versioning things. You can also update via downloading/compiling/installing wasm-component-ld directly and passing -Clinker=/path/to/your/wasm-component-ld

For example, does component-model-async require me to also switch to WASIp3 in lock-step?

Note that component-model-async bits and bobs in in-development at this time. It's expected to not yet be a buttery-smooth experience, so hiccups are to be expected.

Wasmtime GitHub notifications bot (Jan 21 2026 at 22:07):

alexcrichton closed issue #12385:

For context, I found https://github.com/bytecodealliance/wasmtime/issues/12154 which had the same error message but supposedly it's fixed, it may also be unrelated...

...anyway, I'm using wasmtime v41.0.0 enabling the "component-model-async" feature, while still using WASIp2.

The host seems to be happy, but when I build the WASM guest, I'm getting:

cargo build --target wasm32-wasip2 --release
   Compiling wasm-rust-guest-testfixture v0.0.0 (/home/sebastian/projects/trailbase/client/testfixture/guests/rust)
error: linking with `wasm-component-ld` failed: exit status: 1
  |
  = note:  "wasm-component-ld" "-flavor" "wasm" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "cabi_post_trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "cabi_post_trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "trailbase:component/init-endpoint@0.1.0#init-http-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-job-handlers" "--export" "trailbase:component/init-endpoint@0.1.0#init-sqlite-functions" "--export" "trailbase:component/sqlite-function-endpoint@0.1.0#dispatch-scalar-function" "--export" "wasi:http/incoming-handler@0.2.9#handle" "--export" "cabi_realloc" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<431 object files omitted>" "/tmp/rustcvjZFo1/{libwit_bindgen-82480354a7f0311d,libwit_bindgen-07ccf6eb5537f8e1}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/libcompiler_builtins-*.rlib" "-L" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/build/wit-bindgen-8ffd3c9ddbea9b25/out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained" "-o" "/home/sebastian/projects/trailbase/target/wasm32-wasip2/release/deps/wasm_rust_guest_testfixture.wasm" "--gc-sections" "--no-entry" "-O3" "--strip-debug"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: error: failed to parse core wasm for componentization

          Caused by:
              0: decoding custom section component-type:wit-bindgen:0.51.0:trailbase:component@0.1.0:interfaces-with-all-of-its-exports-removed:encoded world
              1: invalid leading byte (0x43) for component defined type (at offset 0x2a38)

When I build with --target wasm-unknown-unknown or --target wasm-wasip1, the component builds but the host is no longer able to load it: "Wasmtime: failed to parse WebAssembly module".

The wasm-wasip3 target seems to be retired? Anyway, which target is the right one to use? Am I holding something else wrong? For example, does component-model-async require me to also switch to WASIp3 in lock-step?

Much appreciated :folded_hands:

Wasmtime GitHub notifications bot (Jan 22 2026 at 21:26):

ignatz commented on issue #12385:

Thanks so much for thoughtfully answering all my questions - much appreciated :folded_hands:

You can fix that by using beta/nightly Rust for example and waiting for those changes to ride their way to stable.

I guess, I was 1-day too impatient. Today's release of Rust 1.93, seems to fix the build.

Note that component-model-async bits and bobs in in-development at this time. It's expected to not yet be a buttery-smooth experience, so hiccups are to be expected.

Understood and thanks for the heads-up.

After also enabling config.wasm_component_model_async(true);, it seems that winch isn't supported for now :+1:

Wasmtime GitHub notifications bot (Jan 22 2026 at 21:32):

ignatz edited a comment on issue #12385:

Thanks so much for thoughtfully answering all my questions - much appreciated :folded_hands:

You can fix that by using beta/nightly Rust for example and waiting for those changes to ride their way to stable.

I guess, I was 1-day too impatient. Today's release of Rust 1.93, seems to fix the build.

Note that component-model-async bits and bobs in in-development at this time. It's expected to not yet be a buttery-smooth experience, so hiccups are to be expected.

Understood and thanks for the heads-up.

After also enabling config.wasm_component_model_async(true);, it seems that winch isn't supported for now :+1:

EDIT: Btw, is there an issue/roadmap I can track to follow the maturation of "component-model-async"? :folded_hands:

Wasmtime GitHub notifications bot (Jan 22 2026 at 22:05):

alexcrichton commented on issue #12385:

Heh how convenient! For the Winch-unsupported part, what was the error you saw there? I think that may just be a bug that Winch is flagged as not supported component-model-async.

For tracking it's unfortunately spread out over a lot of places given the sheer size and scale of the component-model-async project. The highest-level thing to track would be WASIp3's release, so watching releases on the WASI repository, and when 0.3.0 is released things are "ready for general consumption"

Wasmtime GitHub notifications bot (Jan 23 2026 at 08:24):

ignatz commented on issue #12385:

For the Winch-unsupported part, what was the error you saw there? I think that may just be a bug that Winch is flagged as not supported component-model-async.

the wasm_cm_async feature is not supported on this compiler configuration

Stack backtrace:
   0: <anyhow::Error>::msg::<alloc::string::String>
             at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/anyhow-1.0.100/src/backtrace.rs:27:14
   1: <wasmtime::config::Config>::validate
             at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-41.0.0/src/config.rs:2412:17
   2: <wasmtime::engine::Engine>::new
             at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-41.0.0/src/engine.rs:99:47
...

The highest-level thing to track would be WASIp3's release, so watching releases on the WASI repository, and when 0.3.0 is released things are "ready for general consumption"

Much appreciated and thanks for all the great work :folded_hands:

Wasmtime GitHub notifications bot (Jan 23 2026 at 14:41):

ignatz commented on issue #12385:

Since I already got your attention :folded_hands: (and I'm not sure where else to ask, feel free to tell me off or point me the right way).

I'm now running into:

assertion failed: !task.is_null()

which comes from here: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193

, which leads me to believe that I'm missing some guest-side setup ceremony? I'm also using wstd to implement async HTTP handlers with WASIp2 pre component-model-async. I couldn't find any info or issues in the wstd repo, which makes me wonder if I'm just holding it wrong or if this could be a sign of wstd not being ready yet for component-model-async?

Wasmtime GitHub notifications bot (Jan 23 2026 at 17:02):

alexcrichton commented on issue #12385:

Ah right yes that reminded me about the Winch bits. I opened https://github.com/bytecodealliance/wasmtime/issues/12404 to track that, but I remember now that it's expected that Winch doesn't support component-model-async.

Do you have a reproduction you can share for the task.is_null() assertion? That's likely from entering on a sync function and trying to block, but I want to confirm. The precise fix will depend on the details I think.

Wasmtime GitHub notifications bot (Jan 23 2026 at 20:31):

ignatz commented on issue #12385:

Ah right yes that reminded me about the Winch bits. I opened https://github.com/bytecodealliance/wasmtime/issues/12404 to track that, but I remember now that it's expected that Winch doesn't support component-model-async.

:folded_hands:

Do you have a reproduction you can share for the task.is_null() assertion? That's likely from entering on a sync function and trying to block, but I want to confirm. The precise fix will depend on the details I think.

I'd like to be mindful of your time, sadly I don't have a very minimal example. My current playground:

git clone https://github.com/trailbaseio/trailbase.git
cd trailbase
git checkout async-wasm
cd crates/wasm-runtime-host
cargo test -- --no-capture

What happens in a nutshell:

1. The test calls two WASM incoming HTTP endpoints here: https://github.com/trailbaseio/trailbase/blob/31a568ee296376cf62c9d666556aaae40de0149e/crates/wasm-runtime-host/src/lib.rs#L582-L596
2. They're implemented here: https://github.com/trailbaseio/trailbase/blob/31a568ee296376cf62c9d666556aaae40de0149e/client/testfixture/guests/rust/src/lib.rs#L62-L118 via wstd.
3. The first call to /transaction, which succeeds, calls back into a a few synchronous sqlite host endpoint, e.g. here: https://github.com/trailbaseio/trailbase/blob/31a568ee296376cf62c9d666556aaae40de0149e/crates/wasm-runtime-host/src/host.rs#L196
4. Whereas the call to /addDeletePost, which causes the failure, calls back into the host's async WASI outgoing HTTP endpoint implemented here: https://github.com/trailbaseio/trailbase/blob/31a568ee296376cf62c9d666556aaae40de0149e/crates/wasm-runtime-host/src/host.rs#L121-L135

I left some good 'ol prints in the code to make the flow more clear:

running 1 test
calling /transaction
/transaction called

calling /addDeletePost
/addDeletePost called

thread '<unnamed>' (1) panicked at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wit-bindgen-0.51.0/src/rt/async_support/waitable.rs:193:13:
assertion failed: !task.is_null()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Wasmtime GitHub notifications bot (Jan 23 2026 at 20:31):

ignatz edited a comment on issue #12385:

Ah right yes that reminded me about the Winch bits. I opened https://github.com/bytecodealliance/wasmtime/issues/12404 to track that, but I remember now that it's expected that Winch doesn't support component-model-async.

:folded_hands:

Do you have a reproduction you can share for the task.is_null() assertion? That's likely from entering on a sync function and trying to block, but I want to confirm. The precise fix will depend on the details I think.

I'd like to be mindful of your time, sadly I don't have a very minimal example. My current playground:

git clone https://github.com/trailbaseio/trailbase.git
cd trailbase
git checkout async-wasm
cd crates/wasm-runtime-host
cargo test -- --no-capture

What happens in a nutshell:

1. The test calls two WASM incoming HTTP endpoints here: https://github.com/trailbaseio/trailbase/blob/31a568ee296376cf62c9d666556aaae40de0149e/crates/wasm-runtime-host/src/lib.rs#L582-L596
2. They're implemented here: https://github.com/trailbaseio/trailbase/blob/31a568ee296376cf62c9d666556aaae40de0149e/client/testfixture/guests/rust/src/lib.rs#L62-L118 via wstd.
3. The first call to /transaction, which succeeds, calls back into a a few synchronous sqlite host endpoint, e.g. here: https://github.com/trailbaseio/trailbase/blob/31a568ee296376cf62c9d666556aaae40de0149e/crates/wasm-runtime-host/src/host.rs#L196
4. Whereas the call to /addDeletePost, which causes the failure, calls back into the host's async WASI outgoing HTTP endpoint implemented here: https://github.com/trailbaseio/trailbase/blob/31a568ee296376cf62c9d666556aaae40de0149e/crates/wasm-runtime-host/src/host.rs#L121-L135

I left some good 'ol prints in the code to make the flow more clear:

running 1 test
calling /transaction
/transaction called

calling /addDeletePost
/addDeletePost called

thread '<unnamed>' (1) panicked at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wit-bindgen-0.51.0/src/rt/async_support/waitable.rs:193:13:
assertion failed: !task.is_null()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This arguably miles from a minimal example. If you don't have a hunch, I'm happy to break this down further. Much appreciated :folded_hands:

Wasmtime GitHub notifications bot (Jan 23 2026 at 21:30):

alexcrichton commented on issue #12385:

Ok thanks for the pointers. I think what's happening here is that you're using a sync-typed entrypoint (e.g. WASIp2-style) and then invoking some sort of blocking behavior within the guest (e.g. using wstd as an event loop) which is interacting with WASIp3-style-APIs. (correct me if that's wrong though)

If that's the case then the panic you're running into here is that the async bits of wit-bindgen weren't setup during the entrypoint (due to it being sync-style). Even if that were fixed, however, sync-typed functions cannot block, so Wasmtime-the-runtime would still prevent you from calling the blocking function with a trap.

If my description is accurate (enough) then the easiest fix will be to update the wasm entrypoints in WIT to be async-typed. That can be configured as either sync or async at the guest level, but that'll engage the mechanisms in the various places to get it working (I think at least)

Wasmtime GitHub notifications bot (Jan 23 2026 at 22:05):

ignatz commented on issue #12385:

... then invoking some sort of blocking behavior within the guest (e.g. using wstd as an event loop) which is interacting with WASIp3-style-APIs. (correct me if that's wrong though)

Yes, wstd is being used to drive the async event loop. It's interacting with WASIp2-style APIs. I think that's what you meant?

If that's the case then the panic you're running into here is that the async bits of wit-bindgen weren't setup during the entrypoint (due to it being sync-style). Even if that were fixed, however, sync-typed functions cannot block, so Wasmtime-the-runtime would still prevent you from calling the blocking function with a trap.

I'm not sure i got the sync-typed functions cannot block part right. Do you mean that they have to eventually return for the runtime to make progress... And in this case an event-loop is driven indefinitely because it's waiting for the completion of the outgoing http call, which itself cannot make progress because the og entry hasn't returned yet?

If my description is accurate (enough) then the easiest fix will be to update the wasm entrypoints in WIT to be async-typed. That can be configured as either sync or async at the guest level, but that'll engage the mechanisms in the various places to get it working (I think at least)

Since we're talking WASI, this basically means p2 => p3 and the respective changes to wstd (eg fork)?

Much appreciated

Wasmtime GitHub notifications bot (Jan 23 2026 at 22:06):

ignatz edited a comment on issue #12385:

... then invoking some sort of blocking behavior within the guest (e.g. using wstd as an event loop) which is interacting with WASIp3-style-APIs. (correct me if that's wrong though)

Yes, wstd is being used to drive the async event loop. It's interacting with WASIp2-style APIs. I think that's what you meant?

If that's the case then the panic you're running into here is that the async bits of wit-bindgen weren't setup during the entrypoint (due to it being sync-style). Even if that were fixed, however, sync-typed functions cannot block, so Wasmtime-the-runtime would still prevent you from calling the blocking function with a trap.

I'm not sure i got the sync-typed functions cannot block part right. Do you mean that they have to eventually return for the runtime to make progress... And in this case an event-loop is driven indefinitely because it's waiting for the completion of the outgoing http call, which itself cannot make progress because the og entry hasn't returned yet?

If my description is accurate (enough) then the easiest fix will be to update the wasm entrypoints in WIT to be async-typed. That can be configured as either sync or async at the guest level, but that'll engage the mechanisms in the various places to get it working (I think at least)

Since we're talking WASI, this basically means p2 => p3 and the respective changes to wstd (ie fork)?

Much appreciated

Wasmtime GitHub notifications bot (Jan 24 2026 at 00:40):

alexcrichton commented on issue #12385:

Hm ok I may be confusing myself then... My suspicion is that something component-model-async related is getting mixed in with WASIp2-looking things and that's what's causing the issue. What exactly the issue is though depends on further digging in on those details.

Perhaps opening an issue on wstd and going from there with discussion would be best?

Wasmtime GitHub notifications bot (Jan 26 2026 at 15:22):

ignatz commented on issue #12385:

That makes sense and thanks again for your help :folded_hands:

The good or bad news (depending on one's perspective), thus far I've failed to reproduce the issue in a minimal example I was prepping for wstd: https://github.com/ignatz/wstd_poc :thinking:

Wasmtime GitHub notifications bot (Jan 27 2026 at 11:05):

ignatz commented on issue #12385:

Ok, I was finally able to reproduce my issue and boil it down. I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimental :)

Let me still summarize my minimal example here, maybe you're interested and after all your effort, at very least I owe it to you :folded_hands:

The example host is: https://github.com/ignatz/wstd_poc/blob/main/src/main.rs, and the guest is: https://github.com/ignatz/wstd_poc/blob/main/src/main.rs

The Host implements this very simple async function:, which basically just calls tokio::time::sleep, and thus presumably yields execution back to the guest.

Calling this function from a custom async interface exported by the guest works as expected: https://github.com/ignatz/wstd_poc/blob/1affbcea3925f1e5ac34db137a4f5c71e6046dfc/guest/0_6_5/src/lib.rs#L33.

Calling the very same function from an wstd/WASI http handler: https://github.com/ignatz/wstd_poc/blob/main/guest/0_6_5/src/lib.rs#L71 produces:

$ cargo run
Loaded component guest.wasm in: 865.548553ms.
Calling custom async function Guest::test_async
BEFORE
AFTER
Calling HTTP /call_host_test_async
BEFORE

thread '<unnamed>' (1) panicked at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wit-bindgen-0.51.0/src/rt/async_support/waitable.rs:193:13:
assertion failed: !task.is_null()
stack backtrace:
Error: error while executing at wasm backtrace:
    0:  0x44898 - v0_6_5.wasm!abort
    1:  0x36d4a - v0_6_5.wasm!std[6d04a7abd255923a]::sys::pal::wasi::helpers::abort_internal
    2:  0x3416b - v0_6_5.wasm!std[6d04a7abd255923a]::process::abort
    3:  0x349c4 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::__rust_abort
    4:  0x32d93 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::__rust_start_panic
    5:  0x347f1 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::rust_panic
    6:  0x339d6 - v0_6_5.wasm!std[6d04a7abd255923a]::panicking::panic_with_hook
    7:  0x335a8 - v0_6_5.wasm!std[6d04a7abd255923a]::panicking::panic_handler::{closure#0}
    8:  0x3353b - v0_6_5.wasm!std[6d04a7abd255923a]::sys::backtrace::__rust_end_short_backtrace::<std[6d04a7abd255923a]::panicking::panic_handler::{closure#0}, !>
    9:  0x34aa7 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::rust_begin_unwind
   10:  0x4659b - v0_6_5.wasm!core[3471d1c487ddc13e]::panicking::panic_fmt
   11:  0x463e8 - v0_6_5.wasm!core[3471d1c487ddc13e]::panicking::panic
   12:  0x13957 - v0_6_5.wasm!<wit_bindgen[6bf57be79aa08007]::rt::async_support::waitable::WaitableOperation<wit_bindgen[6bf57be79aa08007]::rt::async_support::subtask::SubtaskOps<v0_6_5[6ab12b
dea0a458ea]::wit::foo::bar::import_endpoint::test_async::{closure#0}::_MySubtask>>>::poll_complete_with_code
   13:  0x13fbb - v0_6_5.wasm!<wit_bindgen[6bf57be79aa08007]::rt::async_support::waitable::WaitableOperation<wit_bindgen[6bf57be79aa08007]::rt::async_support::subtask::SubtaskOps<v0_6_5[6ab12b
dea0a458ea]::wit::foo::bar::import_endpoint::test_async::{closure#0}::_MySubtask>> as core[3471d1c487ddc13e]::future::future::Future>::poll
   14:   0x82c9 - v0_6_5.wasm!<core[3471d1c487ddc13e]::pin::Pin<alloc[f027c216b6466811]::boxed::Box<<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http
::incoming_handler::Guest>::handle::{closure#0}>> as core[3471d1c487ddc13e]::future::future::Future>::poll
   15:   0x4e8e - v0_6_5.wasm!<async_task[d918d7eff4be4786]::raw::RawTask<core[3471d1c487ddc13e]::pin::Pin<alloc[f027c216b6466811]::boxed::Box<<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92
e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle::{closure#0}>>, (), <wstd[785ced64e3c98805]::runtime::reactor::Reactor>::spawn_unchecked<<v0_6_5[6ab12bdea0a458ea]
::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle::{closure#0}, ()>::{closure#0}, ()>>::run
   16:  0x167f6 - v0_6_5.wasm!<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle
   17:  0x16af0 - v0_6_5.wasm!wasi:http/incoming-handler@0.2.9#handle

Caused by:
    wasm trap: wasm `unreachable` instruction executed

Repro is simply:

git clone https://github.com/ignatz/wstd_poc.git
cd wstd_poc
cargo run

:folded_hands:

Wasmtime GitHub notifications bot (Jan 27 2026 at 11:06):

ignatz edited a comment on issue #12385:

Ok, I was finally able to reproduce my issue and boil it down. I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimental :)

Let me still summarize my minimal example here, maybe you're interested and after all your effort, at very least I owe it to you :folded_hands:

The example host is: https://github.com/ignatz/wstd_poc/blob/main/src/main.rs, and the guest is: https://github.com/ignatz/wstd_poc/blob/main/guest/0_6_5/src/lib.rs

The Host implements this very simple async function:, which basically just calls tokio::time::sleep, and thus presumably yields execution back to the guest.

Calling this function from a custom async interface exported by the guest works as expected: https://github.com/ignatz/wstd_poc/blob/1affbcea3925f1e5ac34db137a4f5c71e6046dfc/guest/0_6_5/src/lib.rs#L33.

Calling the very same function from an wstd/WASI http handler: https://github.com/ignatz/wstd_poc/blob/main/guest/0_6_5/src/lib.rs#L71 produces:

$ cargo run
Loaded component guest.wasm in: 865.548553ms.
Calling custom async function Guest::test_async
BEFORE
AFTER
Calling HTTP /call_host_test_async
BEFORE

thread '<unnamed>' (1) panicked at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wit-bindgen-0.51.0/src/rt/async_support/waitable.rs:193:13:
assertion failed: !task.is_null()
stack backtrace:
Error: error while executing at wasm backtrace:
    0:  0x44898 - v0_6_5.wasm!abort
    1:  0x36d4a - v0_6_5.wasm!std[6d04a7abd255923a]::sys::pal::wasi::helpers::abort_internal
    2:  0x3416b - v0_6_5.wasm!std[6d04a7abd255923a]::process::abort
    3:  0x349c4 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::__rust_abort
    4:  0x32d93 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::__rust_start_panic
    5:  0x347f1 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::rust_panic
    6:  0x339d6 - v0_6_5.wasm!std[6d04a7abd255923a]::panicking::panic_with_hook
    7:  0x335a8 - v0_6_5.wasm!std[6d04a7abd255923a]::panicking::panic_handler::{closure#0}
    8:  0x3353b - v0_6_5.wasm!std[6d04a7abd255923a]::sys::backtrace::__rust_end_short_backtrace::<std[6d04a7abd255923a]::panicking::panic_handler::{closure#0}, !>
    9:  0x34aa7 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::rust_begin_unwind
   10:  0x4659b - v0_6_5.wasm!core[3471d1c487ddc13e]::panicking::panic_fmt
   11:  0x463e8 - v0_6_5.wasm!core[3471d1c487ddc13e]::panicking::panic
   12:  0x13957 - v0_6_5.wasm!<wit_bindgen[6bf57be79aa08007]::rt::async_support::waitable::WaitableOperation<wit_bindgen[6bf57be79aa08007]::rt::async_support::subtask::SubtaskOps<v0_6_5[6ab12b
dea0a458ea]::wit::foo::bar::import_endpoint::test_async::{closure#0}::_MySubtask>>>::poll_complete_with_code
   13:  0x13fbb - v0_6_5.wasm!<wit_bindgen[6bf57be79aa08007]::rt::async_support::waitable::WaitableOperation<wit_bindgen[6bf57be79aa08007]::rt::async_support::subtask::SubtaskOps<v0_6_5[6ab12b
dea0a458ea]::wit::foo::bar::import_endpoint::test_async::{closure#0}::_MySubtask>> as core[3471d1c487ddc13e]::future::future::Future>::poll
   14:   0x82c9 - v0_6_5.wasm!<core[3471d1c487ddc13e]::pin::Pin<alloc[f027c216b6466811]::boxed::Box<<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http
::incoming_handler::Guest>::handle::{closure#0}>> as core[3471d1c487ddc13e]::future::future::Future>::poll
   15:   0x4e8e - v0_6_5.wasm!<async_task[d918d7eff4be4786]::raw::RawTask<core[3471d1c487ddc13e]::pin::Pin<alloc[f027c216b6466811]::boxed::Box<<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92
e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle::{closure#0}>>, (), <wstd[785ced64e3c98805]::runtime::reactor::Reactor>::spawn_unchecked<<v0_6_5[6ab12bdea0a458ea]
::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle::{closure#0}, ()>::{closure#0}, ()>>::run
   16:  0x167f6 - v0_6_5.wasm!<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle
   17:  0x16af0 - v0_6_5.wasm!wasi:http/incoming-handler@0.2.9#handle

Caused by:
    wasm trap: wasm `unreachable` instruction executed

Repro is simply:

git clone https://github.com/ignatz/wstd_poc.git
cd wstd_poc
cargo run

:folded_hands:

Wasmtime GitHub notifications bot (Jan 27 2026 at 11:36):

ignatz edited a comment on issue #12385:

Ok, I was finally able to reproduce my issue and boil it down. I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimental :)

Let me still summarize my minimal example here, maybe you're interested and after all your effort, at very least I owe it to you :folded_hands:

The example host is: https://github.com/ignatz/wstd_poc/blob/main/src/main.rs, and the guest is: https://github.com/ignatz/wstd_poc/blob/main/guest/0_6_5/src/lib.rs

The Host implements this very simple async function:, which basically just calls tokio::time::sleep, and thus presumably yields execution back to the guest.

Calling this function from a custom async interface exported by the guest works as expected: https://github.com/ignatz/wstd_poc/blob/1affbcea3925f1e5ac34db137a4f5c71e6046dfc/guest/0_6_5/src/lib.rs#L33.

Calling the very same function from an wstd/WASI http handler: https://github.com/ignatz/wstd_poc/blob/main/guest/0_6_5/src/lib.rs#L71 produces:

$ cargo run
Loaded component guest.wasm in: 865.548553ms.
Calling custom async function Guest::test_async
BEFORE
AFTER
Calling HTTP /call_host_test_async
BEFORE

thread '<unnamed>' (1) panicked at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wit-bindgen-0.51.0/src/rt/async_support/waitable.rs:193:13:
assertion failed: !task.is_null()
stack backtrace:
Error: error while executing at wasm backtrace:
    0:  0x44898 - v0_6_5.wasm!abort
    1:  0x36d4a - v0_6_5.wasm!std[6d04a7abd255923a]::sys::pal::wasi::helpers::abort_internal
    2:  0x3416b - v0_6_5.wasm!std[6d04a7abd255923a]::process::abort
    3:  0x349c4 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::__rust_abort
    4:  0x32d93 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::__rust_start_panic
    5:  0x347f1 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::rust_panic
    6:  0x339d6 - v0_6_5.wasm!std[6d04a7abd255923a]::panicking::panic_with_hook
    7:  0x335a8 - v0_6_5.wasm!std[6d04a7abd255923a]::panicking::panic_handler::{closure#0}
    8:  0x3353b - v0_6_5.wasm!std[6d04a7abd255923a]::sys::backtrace::__rust_end_short_backtrace::<std[6d04a7abd255923a]::panicking::panic_handler::{closure#0}, !>
    9:  0x34aa7 - v0_6_5.wasm!__rustc[4aa0cf85fea6adf3]::rust_begin_unwind
   10:  0x4659b - v0_6_5.wasm!core[3471d1c487ddc13e]::panicking::panic_fmt
   11:  0x463e8 - v0_6_5.wasm!core[3471d1c487ddc13e]::panicking::panic
   12:  0x13957 - v0_6_5.wasm!<wit_bindgen[6bf57be79aa08007]::rt::async_support::waitable::WaitableOperation<wit_bindgen[6bf57be79aa08007]::rt::async_support::subtask::SubtaskOps<v0_6_5[6ab12b
dea0a458ea]::wit::foo::bar::import_endpoint::test_async::{closure#0}::_MySubtask>>>::poll_complete_with_code
   13:  0x13fbb - v0_6_5.wasm!<wit_bindgen[6bf57be79aa08007]::rt::async_support::waitable::WaitableOperation<wit_bindgen[6bf57be79aa08007]::rt::async_support::subtask::SubtaskOps<v0_6_5[6ab12b
dea0a458ea]::wit::foo::bar::import_endpoint::test_async::{closure#0}::_MySubtask>> as core[3471d1c487ddc13e]::future::future::Future>::poll
   14:   0x82c9 - v0_6_5.wasm!<core[3471d1c487ddc13e]::pin::Pin<alloc[f027c216b6466811]::boxed::Box<<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http
::incoming_handler::Guest>::handle::{closure#0}>> as core[3471d1c487ddc13e]::future::future::Future>::poll
   15:   0x4e8e - v0_6_5.wasm!<async_task[d918d7eff4be4786]::raw::RawTask<core[3471d1c487ddc13e]::pin::Pin<alloc[f027c216b6466811]::boxed::Box<<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92
e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle::{closure#0}>>, (), <wstd[785ced64e3c98805]::runtime::reactor::Reactor>::spawn_unchecked<<v0_6_5[6ab12bdea0a458ea]
::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle::{closure#0}, ()>::{closure#0}, ()>>::run
   16:  0x167f6 - v0_6_5.wasm!<v0_6_5[6ab12bdea0a458ea]::TheServer as wasip2[92e2552df41e27b4]::proxy::exports::wasi::http::incoming_handler::Guest>::handle
   17:  0x16af0 - v0_6_5.wasm!wasi:http/incoming-handler@0.2.9#handle

Caused by:
    wasm trap: wasm `unreachable` instruction executed

Repro is simply:

git clone https://github.com/ignatz/wstd_poc.git
cd wstd_poc
cargo run

HYPOTHESIS: I'm inclined to think, that this is related to how asynchronicity is handled with p2, where incoming-handler::handle synchronously returns a response-outparam resource, which then handles the asynchronicity independent from the original call.

:folded_hands:

Wasmtime GitHub notifications bot (Jan 27 2026 at 13:59):

pchickey commented on issue #12385:

(wstd maintainer here) that's not going to be a wstd bug, thats mixing up the p2 way of doing Rust async on top of synchronous component model functions, and using the p3 way of doing async at the component model level with a different method to adapt that to work with Rust async. Unfortunately, you can't mix and match the two. When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

Wasmtime GitHub notifications bot (Jan 27 2026 at 14:11):

ignatz commented on issue #12385:

@pchickey thanks for chiming in. Apologies, I never wanted to argue that it's a bug, that's what I tried to say with

I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimentalWhen p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

You're confirming my suspicion that WASIp2 and component-model-async don't play well together:folded_hands:

When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

That makes sense. Off topic but naively I would have hoped that the async component model will make wstd somewhat easier (which clearly doesn't mean that the migration itself wouldn't be a ton of work in itself).

I'm not sure it's worth it, especially being interim, but I do wonder if there's something that could be done to make component-model-async work with WASIp2, e.g. how the "task sets" are handled: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193 :woman_shrugging:

Anyway, thanks y'all :folded_hands:

Wasmtime GitHub notifications bot (Jan 27 2026 at 14:12):

ignatz edited a comment on issue #12385:

@pchickey thanks for chiming in. Apologies, I never wanted to argue that it's a bug, that's what I tried to say with

I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimental

When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

You're confirming my suspicion that WASIp2 and component-model-async don't play well together:folded_hands:

When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

That makes sense. Off topic but naively I would have hoped that the async component model will make wstd somewhat easier (which clearly doesn't mean that the migration itself wouldn't be a ton of work in itself).

I'm not sure it's worth it, especially being interim, but I do wonder if there's something that could be done to make component-model-async work with WASIp2, e.g. how the "task sets" are handled: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193 :woman_shrugging:

Anyway, thanks y'all :folded_hands:

Wasmtime GitHub notifications bot (Jan 27 2026 at 14:12):

ignatz edited a comment on issue #12385:

@pchickey thanks for chiming in. Apologies, I never wanted to argue that it's a bug, that's what I tried to say with

I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimental

...When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

You're confirming my suspicion that WASIp2 and component-model-async don't play well together:folded_hands:

When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

That makes sense. Off topic but naively I would have hoped that the async component model will make wstd somewhat easier (which clearly doesn't mean that the migration itself wouldn't be a ton of work in itself).

I'm not sure it's worth it, especially being interim, but I do wonder if there's something that could be done to make component-model-async work with WASIp2, e.g. how the "task sets" are handled: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193 :woman_shrugging:

Anyway, thanks y'all :folded_hands:

Wasmtime GitHub notifications bot (Jan 27 2026 at 14:13):

ignatz edited a comment on issue #12385:

@pchickey thanks for chiming in. Apologies, I never wanted to argue that it's a bug, that's what I tried to say with

I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimental

...When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

You're confirming my suspicion that WASIp2 and component-model-async don't play well together:folded_hands:

When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

That makes sense. Off topic and naively, I would have hoped that the async component model will make wstd somewhat easier (which clearly doesn't mean that the migration itself wouldn't be a ton of work in itself).

I'm not sure it's worth it, especially being interim, but I do wonder if there's something that could be done to make component-model-async work with WASIp2, e.g. how the "task sets" are handled: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193 :woman_shrugging:

Anyway, thanks y'all :folded_hands:

Wasmtime GitHub notifications bot (Jan 27 2026 at 14:14):

ignatz edited a comment on issue #12385:

@pchickey thanks for chiming in. Apologies, I never wanted to argue that it's a bug, that's what I tried to say with

I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimental

...When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

You're confirming my suspicion that WASIp2 and component-model-async don't play well together:folded_hands:

When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

That makes sense. Off topic and naively, I would have hoped that the async component model will make wstd somewhat easier (which clearly doesn't mean that the migration itself wouldn't be a ton of work in itself).

I'm not sure it's worth it, especially being interim, but I do wonder if there's something that could be done to make component-model-async work with WASIp2, e.g. how the "task sets" are handled: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193 . E.g. could it be kept alive for functions like incoming-handler::handler? :woman_shrugging:

Anyway, thanks y'all :folded_hands:

Wasmtime GitHub notifications bot (Jan 27 2026 at 14:15):

ignatz edited a comment on issue #12385:

@pchickey thanks for chiming in. Apologies, I never wanted to argue that it's a bug, that's what I tried to say with

I'll happily file an issue with wstd, though I somewhat expect the answer to be understandibly component-model-async is experimental

...When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

You're confirming my suspicion that WASIp2 and component-model-async don't play well together:folded_hands:

When p3 stabilizes we will make wstd behave the correct way when used on the wasm32-wasip3 target but in the meantime there is a ton of work on wstd itself needed to make it work on top of async component model.

That makes sense. Off topic and naively, I would have hoped that the async component model will make wstd somewhat easier (which clearly doesn't mean that the migration itself wouldn't be a ton of work in itself).

I'm not sure it's worth it, especially being interim, but I do wonder if there's something that could be done to make component-model-async work with WASIp2, e.g. how the "task sets" are handled: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193 . E.g. could the "task" be kept alive for functions like incoming-handler::handler? :woman_shrugging:

Anyway, thanks y'all :folded_hands:

Wasmtime GitHub notifications bot (Jan 28 2026 at 08:34):

ignatz commented on issue #12385:

Just a last and final thought:

I'm not sure it's worth it, especially being interim, but I do wonder if there's something that could be done to make component-model-async work with WASIp2, e.g. how the "task sets" are handled: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193 . E.g. could the "task" be kept alive for functions like incoming-handler::handler? :woman_shrugging:

Not sure how common practice it is, but if WASI users have followed the same pattern for asynchronicity pre component-model-async, there may be a desire enable this pattern in terms of forward-compatibility and migration story :woman_shrugging:

Thanks again :folded_hands:

Wasmtime GitHub notifications bot (Jan 28 2026 at 08:35):

ignatz edited a comment on issue #12385:

Just a last and final thought:

I'm not sure it's worth it, especially being interim, but I do wonder if there's something that could be done to make component-model-async work with WASIp2, e.g. how the "task sets" are handled: https://github.com/bytecodealliance/wit-bindgen/blob/350e8ad7abe8f65357c8984535d7bca5b9882c2c/crates/guest-rust/src/rt/async_support/waitable.rs#L193 . E.g. could the "task" be kept alive for functions like incoming-handler::handler? :woman_shrugging:

Not sure how common practice it is, but if WASI users have followed the same pattern for asynchronicity for their own interfaces pre component-model-async, there may be a desire enable this pattern in terms of forward-compatibility and migration story :woman_shrugging:

Thanks again :folded_hands:

Last updated: Jan 29 2026 at 13:25 UTC