Stream: git-wasmtime

Topic: wasmtime / issue #11249 Generated guest export bindings a...

Wasmtime GitHub notifications bot (Jul 15 2025 at 17:56):

rvolosatovs opened issue #11249:

Since https://github.com/bytecodealliance/wasmtime/pull/11238 has been merged, calling an async export requires an Accessor, however, the only way to get an Accessor is to use an Instance.

Users relying uniquely on generated instantiate_async bindings do not have access to one and so can never call the async export.

Steps to Reproduce

• checkout #11221
• cargo doc -p wasmtime-wasi --features p3 --open --document-private-items
• take a look at docs generated for target/doc/wasmtime_wasi/p3/bindings/struct.Command.html

<img width="978" height="657" alt="Image" src="https://github.com/user-attachments/assets/b353638d-f7a5-4179-a6bc-a5c50f9df24d" />
<img width="611" height="435" alt="Image" src="https://github.com/user-attachments/assets/1a88d5de-720c-45e6-88dd-35da78b4d61e" />

Expected Results

Either a way to run an export without manual instantiation or removal of these bindings

Actual Results

"dead end" from user's perspective with seemingly no way of constructing an Accessor using the public API

Versions and Environment

Wasmtime version or commit: 326795f583 (latest main)

Operating system: MacOS

Architecture: aarch64-darwin

Extra Info

Without changing wasmtime API, there seem to be two ways to fix this issue:

• return a tuple from instantiate_async e.g. (Command, Instance) (and similar for other worlds)
• simply remove the instantiate_async generated functions and require users to always instantiate manually and rely on Command::new (and similar for other worlds)

Wasmtime GitHub notifications bot (Jul 15 2025 at 17:56):

rvolosatovs added the bug label to Issue #11249.

Wasmtime GitHub notifications bot (Jul 15 2025 at 17:58):

alexcrichton added the wasm-proposal:component-model-async label to Issue #11249.

Wasmtime GitHub notifications bot (Jul 15 2025 at 22:06):

alexcrichton commented on issue #11249:

In the limit this will be resolved by https://github.com/bytecodealliance/wasmtime/issues/11226 because you won't need an instance to acquire an accessor, you can instead acquire that from the store. Until that point though is it ok to use the instance and less-nice auto-generated bindings as a workaround?

Wasmtime GitHub notifications bot (Jul 15 2025 at 22:06):

alexcrichton removed the bug label from Issue #11249.

Wasmtime GitHub notifications bot (Jul 16 2025 at 09:12):

rvolosatovs commented on issue #11249:

In the limit this will be resolved by https://github.com/bytecodealliance/wasmtime/issues/11226 because you won't need an instance to acquire an accessor, you can instead acquire that from the store. Until that point though is it ok to use the instance and less-nice auto-generated bindings as a workaround?

Sounds good to me!

Wasmtime GitHub notifications bot (Sep 15 2025 at 16:01):

alexcrichton assigned dicej to issue #11249.

Wasmtime GitHub notifications bot (Oct 06 2025 at 20:16):

dicej closed issue #11249:

Since https://github.com/bytecodealliance/wasmtime/pull/11238 has been merged, calling an async export requires an Accessor, however, the only way to get an Accessor is to use an Instance.

Users relying uniquely on generated instantiate_async bindings do not have access to one and so can never call the async export.

Steps to Reproduce

• checkout #11221
• cargo doc -p wasmtime-wasi --features p3 --open --document-private-items
• take a look at docs generated for target/doc/wasmtime_wasi/p3/bindings/struct.Command.html

<img width="978" height="657" alt="Image" src="https://github.com/user-attachments/assets/b353638d-f7a5-4179-a6bc-a5c50f9df24d" />
<img width="611" height="435" alt="Image" src="https://github.com/user-attachments/assets/1a88d5de-720c-45e6-88dd-35da78b4d61e" />

Expected Results

Either a way to run an export without manual instantiation or removal of these bindings

Actual Results

"dead end" from user's perspective with seemingly no way of constructing an Accessor using the public API

Versions and Environment

Wasmtime version or commit: 326795f583 (latest main)

Operating system: MacOS

Architecture: aarch64-darwin

Extra Info

Without changing wasmtime API, there seem to be two ways to fix this issue:

• return a tuple from instantiate_async e.g. (Command, Instance) (and similar for other worlds)
• simply remove the instantiate_async generated functions and require users to always instantiate manually and rely on Command::new (and similar for other worlds)

Last updated: Dec 06 2025 at 06:05 UTC