Stream: git-wasmtime

Topic: wasmtime / issue #7266 `wasi:http` bleeding into the prev...

Wasmtime GitHub notifications bot (Oct 17 2023 at 12:32):

rvolosatovs added the bug label to Issue #7266.

Wasmtime GitHub notifications bot (Oct 17 2023 at 12:32):

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 no incoming-body type exists in the adapter

Actual 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.

Wasmtime GitHub notifications bot (Oct 17 2023 at 12:54):

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 no incoming-body type exists in the adapter

Actual 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.

Wasmtime GitHub notifications bot (Oct 17 2023 at 15:21):

alexcrichton commented on issue #7266:

Looking into this the issue appears to be:

• The Resolve for the world used to create the adapter has wasi:http in it. This is because the wasmtime:wasi package that's used to pull everything together has worlds in it that depend on wasi: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 entire Resolve 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 two Resolve 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 the wasmtime:wasi/preview1-adapter-reactor world for example. Such filtering should remove the encoding of wasi:http types and interfaces, meaning they'll be entirely gone from the adapter.

Such a change must happen in wit-component in the wasm-tools repository. I'll wait for https://github.com/bytecodealliance/wasm-tools/pull/1252 to finish before implementing this.

Wasmtime GitHub notifications bot (Oct 20 2023 at 18:34):

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 tested main 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 updated wit-component, however.

Wasmtime GitHub notifications bot (Mar 26 2024 at 03:17):

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 no incoming-body type exists in the adapter

Actual 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.

Wasmtime GitHub notifications bot (Mar 26 2024 at 03:17):

alexcrichton commented on issue #7266:

I believe this has since been fixed, so closing.

Last updated: Dec 13 2025 at 21:03 UTC