Conversation
|
Okay the multiple implementations of FuturePayload might be a wit-bindgen versioning thing. That part of the code uses wit-bindgen 0.51. If I change it to 0.53 I get different errors instead ("proc macro panicked ... no entry found for key"). |
| let ksr = StreamReader::new(&mut access, producer) | ||
| .map_err(|e| anyhow!("stream error {e}"))?; | ||
| let efr = | ||
| FutureReader::new(&mut access, err_rx).map_err(|e| anyhow!("future error {e}"))?; | ||
| anyhow::Ok((ksr, efr)) | ||
| })?; |
There was a problem hiding this comment.
For these changes, was the map_err required due to type inference otherwise not being able to figure things out? If so I think that can be solved by:
let (ksr, efr) = accessor.with(|mut access| -> wasmtime::Result<_> {
let ksr = StreamReader::new(&mut access, producer)?;
let efr = FutureReader::new(&mut access, err_rx)?;
Ok((ksr, efr))
})?;which may be a bit more ergonomic than map_err
There was a problem hiding this comment.
I was able to drop the map_err but still needed the anyhow::Ok - for me that felt more ergonomic than writing out the return type on the closure. Thanks for prompting me to revisit!
| const WASI_HTTP_EXPORT_0_2_PREFIX: &str = "wasi:http/incoming-handler@0.2"; | ||
| /// The `handler` export `wasi:http` version 0.3.0-rc-2025-08-15 | ||
| const WASI_HTTP_EXPORT_0_3_0_UNSTABLE: &str = "wasi:http/handler@0.3.0-rc-2026-01-06"; | ||
| const WASI_HTTP_EXPORT_0_3_0_RC_02: &str = "wasi:http/handler@0.3.0-rc-2026-02-09"; |
There was a problem hiding this comment.
I mentioned this on Slack but to also mention it here but I'm hoping to backport bytecodealliance/wasmtime#12781 to the 43.0.0 release so this'll want to update to the 03-15 snapshot if/when that happens.
itowlson
force-pushed
the
wasmtime-43-readiness
branch
2 times, most recently
from
295d918 to
cce49e4
Compare
|
I'll retry the build once bytecodealliance/wasmtime#12795 goes through to confirm the remaining errors go away and try to help squash any further ones that crop up. |
itowlson
force-pushed
the
wasmtime-43-readiness
branch
from
c6365b7 to
c4fbc1e
Compare
| #[instrument( | ||
| name = "spin_outbound_http.send_request", | ||
| skip_all, | ||
| fields( | ||
| otel.kind = "client", | ||
| url.full = Empty, | ||
| http.request.method = %request.method(), | ||
| otel.name = %request.method(), | ||
| http.response.status_code = Empty, | ||
| server.address = Empty, | ||
| server.port = Empty, | ||
| ) | ||
| )] |
There was a problem hiding this comment.
This might be the reason for the failing tests, I think I lost this in an intermediate refactoring of mine but it should be fine to plop onto send_request below
itowlson
force-pushed
the
wasmtime-43-readiness
branch
from
173c8dc to
b50a029
Compare
|
Updated to Wasmtime 43 release. |
|
For the We could leave it defined and produce a more beautiful error. I don't reckon it's worth it. But if other folks think we should handle this more gracefully then I'm happy to be talked round. |
|
@itowlson re: the output above, +1 i'm OK with the output as it stands from these changes. |
Signed-off-by: itowlson <ivan.towlson@fermyon.com>
itowlson
force-pushed
the
wasmtime-43-readiness
branch
from
cdf1e9a to
17d19d4
Compare
|
Last push was just squashing commits |
dicej
left a comment
dicej
left a comment
There was a problem hiding this comment.
Thanks so much for doing this!
4 participants
I did this to get WITs and futures and stuff in order, generally to have awareness of what the upgrade would look like or if there were any issues. Obviously not ready for merge yet!
I have not yet removed unstable warnings etc. but pushed because...
There's something weird with the binding in the tests, multiply implementing FuturePayload on a single type. Not sure if this is me screwing up the WITs or the versioning or what, but I can reproduce it in vanilla projects.