Wasmtime GitHub notifications bot (Oct 19 2026 at 22:08): Wasmtime GitHub notifications bot (Oct 19 2026 at 22:08):jrandolf opened PR #14871 from jrandolf:resource-trap-message to bytecodealliance:main:
Using a resource handle with the wrong type trapped with "expected guest-defined resource but found a different guest-defined resource", even when the resources involved are defined by the host. One way to hit this: a component imports the same interface under two labels, the host defines both with the same Rust type, and the guest passes a
primary.rhandle tosecondary.use. The types compared at that point are static types within the component, so whether a resource is guest-defined isn't known there. The message is now "found a handle to a different resource type".The upstream component-model tests (
resources/handle-table.wast) check for the old wording, so the wast harness maps it to the new one, like it already does for a few other spec-test messages.This also documents, on
LinkerInstance::resourceand in thenamed_importsdocs, that each import of a resource is a distinct resource type within the component, so handles can't be passed between imports. It also drops the outdated note sayingnamed_importsdoesn't support resources.What this leaves open from #14861: the spec's runtime check (
h.rt is not t.rt) would allow a handle to move between two imports that the host backs with the same resource type, while Wasmtime rejects it. Is that difference intended? If not, I'm happy to look into matching the spec.Fixes part of #14861
Last updated: Oct 31 2026 at 23:03 UTC