Roman Volosatovs (Sep 04 2023 at 19:58): Roman Volosatovs (Sep 04 2023 at 19:58):As briefly discussed in last component model meeting, it appears that somehow wasi:http is bleeding into the WASI preview1 adapter. Unfortunately, I do not have time to produce a minimized reproducer right now, but here's a way to reproduce it in context of wasmCloud:
This commit https://github.com/rvolosatovs/wasmCloud/commit/739373ccd114bf47e8991d79ca18327cdd921d98 causes this error (e.g. https://github.com/rvolosatovs/wasmCloud/actions/runs/6077133453/job/16486311720):
Error: failed to encode `/home/rvolosatovs/src/github.com/wasmCloud/wasmCloud/target/debug/build/test-actors-255025094142f50f/out/rust-builtins-component-reactor.wasm`
Caused by:
0: failed to add WASI adapter
1: failed to merge WIT packages of adapter `wasi_snapshot_preview1` into main packages
2: failed to merge package `wasi:http` into existing copy
3: failed to merge interface `types`
4: expected function `incoming-request-path` to be present
Which originates here https://github.com/rvolosatovs/wasmCloud/blob/739373ccd114bf47e8991d79ca18327cdd921d98/tests/actors/build.rs#L297-L302
Here's the component https://github.com/rvolosatovs/wasmCloud/blob/chore/upstream-http/tests/actors/rust/builtins-component-reactor/src/lib.rs
Here's the WIT https://github.com/rvolosatovs/wasmCloud/blob/739373ccd114bf47e8991d79ca18327cdd921d98/tests/actors/rust/builtins-component-reactor/wit/actor.wit#L1-L5
It also transitively pulls in this WIT
cc @Alex Crichton @Joel Dice
Eduardo Rodrigues (Sep 04 2023 at 21:03):i believe i ran into the same issue and had to use the wit definition as specified in the wasmtime-wasi crate here
Roman Volosatovs (Sep 04 2023 at 23:00):Right, so we fixed that by renaming the types, but the point is that there should not be anything related to wasi:http inside the adapter (because the error is triggered by composing the component, it's not a Wasmtime runtime error)
Alex Crichton (Sep 05 2023 at 13:58):Thanks! I'll try to take a look at this some time this week
Alex Crichton (Sep 05 2023 at 21:13):Looks like the adapters are coming from wasmcloud-component-adapters as a crate. I added that to a project and the *.command.wasm adapter does not reference wasi:http, but the *.reactor.wasm does. Looking at the source for this crate it looks like these adapters are downloaded from nix things (sorry I don't really understand what's going on here with nix). I see references to the 12.0.1 download URLs. I can confirm though that the 12.0.1 artifacts from Wasmtime have wasi:http in the *.reactor.wasm as well, but not *.command.wasm.
Looks like though on the dev tag neither have the wasi:http interfaces, so this may have been a transient issue fixed on main?
Roman Volosatovs (Sep 05 2023 at 23:02):thanks for looking into this!
Nix is just used there for vendoring really, we're pulling the adapters from the Wasmtime release page and validate the contents using the digests computed by Nix and stored in flake.lock.
If this is fixed in main, any chance this could land in a patch release for Wasmtime 12?
Alex Crichton (Sep 05 2023 at 23:07):perhaps! I'm not sure what fixed it so I don't know what that would look like
Roman Volosatovs (Sep 08 2023 at 21:54):I just tested the adapter I built from @Pat Hickey 's pch/backpressure_2 branch and can confirm it is fixed. Pat mentioned it could have something to do with the build process pulling in all dependencies in the wit/deps directory before
Roman Volosatovs (Oct 17 2023 at 12:50):@Alex Crichton @Pat Hickey @Joel Dice looks like the issue might have appeared to be fixed due to dependencies accidentally being in sync, I hit it again with adapter from Wasmtime dev and wasi:http mismatch
https://github.com/bytecodealliance/wasmtime/issues/7266
https://github.com/rvolosatovs/wasmtime-adapter-http-repro
Alex Crichton (Oct 17 2023 at 14:19):Thanks for the issue/repro! I'll dig in today
Last updated: Dec 23 2024 at 13:07 UTC