wit-parser panic on import + re-export of resource-bearing instance

[ejrgilbert]

wit_component::decode (and wasm-tools component wit) panic with assertion failed: prev.is_none() at wit-parser/src/decoding.rs:1085 when given a valid component that imports a resource-bearing interface and re-exports the same imported instance under a different name.

Repro

(component
    (type (;0;) (instance (export "request" (type (sub resource))))
    )
    (import "impl:test/handler" (instance (;0;) (type 0)))
    (export "wasi:http/handler@0.3.0" (instance 0))
)

$ wasm-tools parse repro.wat -o repro.wasm
$ wasm-tools validate --features=all repro.wasm
$ echo $?
0
$ wasm-tools component wit repro.wasm
thread 'main' panicked at /…/wit-parser-0.247.0/src/decoding.rs:1085:9:
assertion failed: prev.is_none()

Expected

The component validates as well-formed (wasm-tools validate --features=all exits 0), so wit-parser should either decode it successfully or return a structured Err, not panic.

Actual

WitPackageDecoder::register_type_export allocates a fresh TypeId for the re-exported request resource and inserts it into self.resources[owner][name]. The map already has an entry from the import-side decoding, so the assert!(prev.is_none()) on line 1085 fires. Backtrace tail:

wit_parser::decoding::WitPackageDecoder::register_type_export at decoding.rs:1085
wit_parser::decoding::WitPackageDecoder::register_import     at decoding.rs:821
wit_parser::decoding::WitPackageDecoder::decode_component_export at decoding.rs:724
wit_parser::decoding::ComponentInfo::decode_component        at decoding.rs:340
wit_parser::decoding::decode_reader                          at decoding.rs:404
wit_parser::decoding::decode                                 at decoding.rs:416

Why I hit this

I'm building a tool that generates a wrapper component around an existing component: the wrapper imports the original interface and re-exports it under the same canonical name (so downstream callers see no difference).
When the wrapped interface contains a resource (e.g. wasi:http/handler with request / response), wit_component::decode panics on the wrapper's bytes even though they validate cleanly. The minimal repro above is exactly that shape, stripped down to a single resource and a single wrapper-style re-export.

Versions

• wasm-tools CLI: 1.247.0
• wit-parser: 0.247.0
• wit-component: 0.247.0

(haven't bisected to find the first affected version)

Notes

• The same pattern with the resource type defined inline in the component (rather than imported from a sibling instance) decodes fine. It's specifically the alias chain through the import that confuses the resource-name registration.
• A defensible fix would be to teach register_type_export to follow the alias chain and reuse the existing resource registration when the referenced type traces back to one already in self.resources[owner], instead of asserting.
• Even if the fix is non-trivial, replacing the assert! with a structured bail! would let downstream tools recover gracefully.

[alexcrichton]

Thanks for the report! It's somewhat expected that the decoding process is not 100% robust to any-valid-component coming in right now, it's generally only expected to work on previously-wit-component-encoded components. Not to say this isn't a bug, but mostly to give you a heads up that is is unlikely to be the only class of bug of "decoding panics on valid components".

I'd have to dig in further here, but my hunch is that this isn't a regression and it's always been a problem. My hunch as well is that the fix here is to use wasmparser's type information more faithfully rather than using parsed information raw, as that may be what's happening here (I forget).

[ejrgilbert]

Hopefully it's not too complex a fix and winds up being a quick impl :) And yes, my use case is a bit off the beaten path. I'm trying to defer as much as possible to libs like wit-parser, wit-bindgen-core, etc. to keep from having to maintain all this complexity myself. These libs have honestly been a lifesaver for this project!

[alexcrichton]

Oh! I misread the original input here. This is actually showcasing a component model feature that's entirely unsupported in WIT. I didn't read this close enough and missed the reexport part, I thought that this was reusing a type definition for two different instances but this is actually reexporing an import as an export.

In light of that, there's not actually even syntax in WIT to describe this world at this time. I think to do this we'd need some sort of first-class syntax in a world. There's various proposals for various pieces of syntax to support something like this, but I don't think anything in-progress being proposed would satisfy this exactly.

Would you be up for opening an issue for this on the component-model repo itself? That unfortuantely makes this a much larger and more invasive issue, however :(