Stream: git-wasmtime

Topic: wasmtime / issue #12465 `ResourceAny` API ergonomics


view this post on Zulip Wasmtime GitHub notifications bot (Jan 29 2026 at 10:27):

crepererum opened issue #12465:

Feature

ResourceAny is in the component model, both when the guest returns resources but also when borrow<...> resources are passed to the guest. The ResourceAny type Copyable handle and is usually passed by value. To destroy a resource resource_drop[_async] is called. Since the handle itself is Copy, you may still have copies of that handle around. Accidently reusing the handle results in:

host-owned resource is being used with the wrong type

as this test shows:

https://github.com/bytecodealliance/wasmtime/blob/23c0f09d0ba1041fc300bc4aabada0ded783c538/tests/all/component_model/resources.rs#L181-L203

Now there are two DX issues here:

Benefit

Improving the situation may prevent certain "used after free" bugs (even though they don't panic or SEGFAULT, they are still not great)

Implementation

Ideally ResourceAny wouldn't be Copy and would be passed by reference. Then resource_drop[_async] could consume the type. However there might be other API considerations that could prevent that.

Alternatives

If the type stays Copy, could we at least make the error message a bit clearer?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 29 2026 at 17:14):

fitzgen added the wasmtime:api label to Issue #12465.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 29 2026 at 17:14):

fitzgen added the wasm-proposal:component-model label to Issue #12465.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 29 2026 at 17:15):

fitzgen commented on issue #12465:

cc @alexcrichton @rvolosatovs

view this post on Zulip Wasmtime GitHub notifications bot (Jan 29 2026 at 18:53):

alexcrichton commented on issue #12465:

This is definitely a known deficiency of the API design of ResourceAny, but it was currently designed as a sort of least-bad version of the functionality to provide. Destroying a resource, or cloning a resource, requires access to a store which means that this can't use normal Rust traits. Additionally destroying a resource involves executing WebAssembly meaning it might be an async operation.

I do think that the error messages could be improved here, yeah, but I'm not aware of a great way to manage the resource here in a more automatic Rust-y fashion.


Last updated: Feb 24 2026 at 04:36 UTC