rvolosatovs added the bug label to Issue #7266.
rvolosatovs opened issue #7266:
Test Case
https://github.com/rvolosatovs/wasmtime-adapter-http-repro
Steps to Reproduce
- clone https://github.com/rvolosatovs/wasmtime-adapter-http-repro
curl -sL https://github.com/bytecodealliance/wasmtime/releases/download/dev/wasi_snapshot_preview1.reactor.wasm | cargo run
Expected Results
Success, especially because
wasm-tools print
suggests noincoming-body
type exists in the adapterActual Results
Failure to encode a component
Versions and Environment
dev
(9e4d44626a008f8a1b1b3b4a48f0d5693185844b)Operating system: linux
Architecture: x86_64
Extra Info
We have seen this issue before @dicej @alexcrichton @pchickey, it appeared that it was fixed, but perhaps that was because the component and adapter definitions happened to be in sync during testing.
rvolosatovs edited issue #7266:
Test Case
https://github.com/rvolosatovs/wasmtime-adapter-http-repro
Steps to Reproduce
- clone https://github.com/rvolosatovs/wasmtime-adapter-http-repro
curl -sL https://github.com/bytecodealliance/wasmtime/releases/download/dev/wasi_snapshot_preview1.reactor.wasm | cargo run
Expected Results
Success, especially because
wasm-tools print
suggests noincoming-body
type exists in the adapterActual Results
Failure to encode a component
Versions and Environment
dev
(9e4d44626a008f8a1b1b3b4a48f0d5693185844b)Operating system: linux
Architecture: x86_64
Extra Info
We have seen this issue before @dicej @alexcrichton @pchickey, it appeared that it was fixed, but perhaps that was because the component and adapter definitions happened to be in sync during testing.
alexcrichton commented on issue #7266:
Looking into this the issue appears to be:
- The
Resolve
for the world used to create the adapter haswasi:http
in it. This is because thewasmtime:wasi
package that's used to pull everything together has worlds in it that depend onwasi:http
.- When the adapter is produced the
wasmtime:wasi
package is serialized into binary and embedded within the adapter itself.- When the adapter is processed by
wit-component
it will deserialize this information into an entireResolve
and then merge it with the target resolve.This means that even though the adapter itself doesn't use the
wasi:http
interfaces the merge step of twoResolve
items still attempts to merge them together. The best fix that I can think of is to filter out items during the encoding phase so only the relevant types are encoded, namely just thewasmtime:wasi/preview1-adapter-reactor
world for example. Such filtering should remove the encoding ofwasi:http
types and interfaces, meaning they'll be entirely gone from the adapter.Such a change must happen in
wit-component
in thewasm-tools
repository. I'll wait for https://github.com/bytecodealliance/wasm-tools/pull/1252 to finish before implementing this.
alexcrichton commented on issue #7266:
Ok I've looked again at this and this should be solved by https://github.com/bytecodealliance/wasm-tools/pull/1260. The issue doesn't actually reproduce as-is today due to the introduction of versions on
main
which means merging now succeeds, but I've testedmain
just before versions came in and was able to reproduce this issue and test that https://github.com/bytecodealliance/wasm-tools/pull/1260 fixes things.The fix there will be a bit delayed due to the fact that we'll have it off-by-default for a bit. Eventually down the road we'll switch the adapter to using the new metadata format by default, but until that point this bug will still be present. You can compile your own adapter, however, and specify
WIT_COMPONENT_NEW_ENCODE=1
to build an adapter with the new format to fix this issue. This does depend on all pices of the system using an updatedwit-component
, however.
alexcrichton closed issue #7266:
Test Case
https://github.com/rvolosatovs/wasmtime-adapter-http-repro
Steps to Reproduce
- clone https://github.com/rvolosatovs/wasmtime-adapter-http-repro
curl -sL https://github.com/bytecodealliance/wasmtime/releases/download/dev/wasi_snapshot_preview1.reactor.wasm | cargo run
Expected Results
Success, especially because
wasm-tools print
suggests noincoming-body
type exists in the adapterActual Results
Failure to encode a component
Versions and Environment
dev
(9e4d44626a008f8a1b1b3b4a48f0d5693185844b)Operating system: linux
Architecture: x86_64
Extra Info
We have seen this issue before @dicej @alexcrichton @pchickey, it appeared that it was fixed, but perhaps that was because the component and adapter definitions happened to be in sync during testing.
alexcrichton commented on issue #7266:
I believe this has since been fixed, so closing.
Last updated: Dec 23 2024 at 12:05 UTC