Add aws-smithy-wasm crate with WASI http client
#3409
Conversation
chore: fix formatting
Added a Builder to allow for future configuration to be baked in in a backwards compatible manner. Also updated some of the error handling. Updated the associated tests to use the new Builder and to not send a network call. Sending the actual network call will be moved to the canary in another commit. Undoing some autoformatting in the Dockerfile Lint fixes
It compiles and the wasm runs, although unsuccessfully due to some missing WASI imports. Still trying to figure that out.
Unfortunately having trouble making the canary run `async` because there is a tokio error.
Updating some lints
|
Ok pending this final CI run this should be all good to go. As requested I added a new canary Currently the canary only tests a simple Note: There is one CI task that continues to fail, the |
| let converted_req = http_req.map(|body| match body.bytes() { | ||
| Some(value) => Bytes::copy_from_slice(value), | ||
| None => Bytes::new(), | ||
| }); |
There was a problem hiding this comment.
Are streaming request bodies possible in WASI?
There was a problem hiding this comment.
They are not yet possible, but they will be when WASI preview 3 launches. Streaming bodies are waiting on native async support in wasm components. There is some detail around streaming bodies in the proposal for async/preview 3
| let read_timeout = value | ||
| .read_timeout() | ||
| .map(|dur| u64::try_from(dur.as_nanos()).unwrap_or(u64::MAX)); |
There was a problem hiding this comment.
Is there a difference between not calling the set_*_timeout methods and setting it to u64::MAX?
There was a problem hiding this comment.
If they aren't called the default appears to be 600,000 milliseconds (set here). But this is set in wasmtime and not by the WASI bindings, so it seems to be host dependent. To be consistent with that I can change the u64::MAX to match their 600 seconds default.
There was a problem hiding this comment.
Breaking this down a little more:
The behavior of set_*_timeout:
set_*_timeoutis never called - then the default timeout (for all of them) is set to600seconds (code). Note that we don't encounter this in our code since the timeouts are always set based on theHttpConnectorSettingsvalues.set_*_timeoutis called withNone- the timeout is set to 0 (code)set_*_timeoutis called withSome(u64)- timeout is set to theu64value
The behavior of WasiRequestOptions::from(HttpConnectorSettings):
- The
HttpConnectorSettingscontains a timeout value (u128) less thanu64::MAX- Then the corresponding timeout value onoutgoing_handler::RequestOptionsis set to that value (cast to au64) - The
HttpConnectorSettingscontains a timeout value (u128) greater thanu64::MAX- Then the value is clamped tou64::MAXand set to that - The
HttpConnectorSettingscontains aNonefor the timeout -set_*_timeoutis called withNoneand thus the timeout is set to 0 (see above)
There was a problem hiding this comment.
Added comments explaining the clamping in c883aad
Co-authored-by: John DiSanti <[email protected]>
Remove WasmSleep in favor of existing TokioSleep Update the targeting in wasm crates dependencies Updating comments around setting timeouts
Moving wasmtime-cli off nightly since MSRV bump Removing all dependency targeting to appease tests Removing the target on the deps in aws-smithy-wasm's Cargo.toml caused the cargo udeps tests to fail indicating those were unused dependencies. This was caused by the target clause on pub mod wasi in the crate's lib.rs, so that also had to be removed.
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
Co-authored-by: John DiSanti <[email protected]>
Motivation and Context
This change adds a new crate,
aws-smithy-wasm, that exports a SDK compatible WASI http client. This is a continuation of the work in #2520 using the now stabilized WASI 0.2.0 interfaces from the wasi crate. This supports, but does not finalize the work for #2087Description
Add a new crate,
aws-smithy-wasmwhich exports a functionwasi_http_clientthat will provide the user with a WASI compatible http client. This client is implemented by using thewasi::http::outgoing_handlerref along with some utility implementations ofTryFromto transform back and worth between the types from thehttpcrate and thewasi::httptypes. It also exports a unit structWasmSleepthat impls theAsyncSleeptrait needed by the SDK.Testing
This is tested via an integration test in
aws/sdk/integration-tests/webassemblythat uses the wasi http-client to vuild a config and an operation (that is not sent). It is further tested in a new canary (wasm_canary) that calls the S3list_objects_v2API.Checklist
CHANGELOG.next.tomlif I made changes to the smithy-rs codegen or runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.