crepererum opened issue #12465:
Feature
ResourceAnyis in the component model, both when the guest returns resources but also whenborrow<...>resources are passed to the guest. TheResourceAnytypeCopyable handle and is usually passed by value. To destroy a resourceresource_drop[_async]is called. Since the handle itself isCopy, you may still have copies of that handle around. Accidently reusing the handle results in:host-owned resource is being used with the wrong typeas this test shows:
Now there are two DX issues here:
- the error message is somewhat misleading (it actually even happens when you allocate the same resource type into the slot, i.e. if the test would have used
t1&t1instead oftandu)- since the handle doesn't have any form of refcounting, it is hard to enforce a "don't reuse a de-allocated resource" in a codebase esp. since
ResourceAnyisCopyand is often passed by value, hence you cannot really build a strong ref-count guard around itBenefit
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
ResourceAnywouldn't beCopyand would be passed by reference. Thenresource_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?
fitzgen added the wasmtime:api label to Issue #12465.
fitzgen added the wasm-proposal:component-model label to Issue #12465.
fitzgen commented on issue #12465:
cc @alexcrichton @rvolosatovs
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