## Motivation and Context
A step towards moving to http-1.0
https://github.com/awslabs/aws-sdk-rust/issues/1046
(Russell): This is a minimal implementation of `http-body = 1`. It isn't
maximally efficient since even if we were given a 1x body, we convert it
back and forth first. This is a first step.
## Description
Implements http-body-1.0 Body trait for SdkBody.
## Testing
Regular CI
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Russell Cohen <rcoh@amazon.com>
Co-authored-by: Russell Cohen <russell.r.cohen@gmail.com>
Co-authored-by: John DiSanti <john@vinylsquid.com>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
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](https://crates.io/crates/wasi). This supports, but does not
finalize the work for #2087
## Description
<!--- Describe your changes in detail -->
Add a new crate, `aws-smithy-wasm` which exports a function
`wasi_http_client` that will provide the user with a WASI compatible
http client. This client is implemented by using the
`wasi::http::outgoing_handler`
[ref](https://docs.rs/wasi/0.12.0+wasi-0.2.0/wasi/http/outgoing_handler/index.html)
along with some utility implementations of `TryFrom` to transform back
and worth between the types from the `http` crate and the `wasi::http`
types. It also exports a unit struct `WasmSleep` that impls the
`AsyncSleep` trait needed by the SDK.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
This is tested via an integration test in
`aws/sdk/integration-tests/webassembly` that 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 S3
`list_objects_v2` API.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [X] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Eduardo Rodrigues <eduardomourar@users.noreply.github.com>
Co-authored-by: Eduardo de Moura Rodrigues <16357187+eduardomourar@users.noreply.github.com>
Co-authored-by: ysaito1001 <awsaito@amazon.com>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
Co-authored-by: Russell Cohen <rcoh@amazon.com>
Co-authored-by: John DiSanti <john@vinylsquid.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Because the build pipeline is checking for these.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Make it easier to understand why credentials are expired. New log
example:
```
2024-02-19T17:47:31.769924Z INFO lazy_load_identity: aws_smithy_runtime::client::identity::cache::lazy: identity cache miss occurred; added new identity (took 861.893ms) new_expiration=2024-02-19T18:47:31Z valid_for=3599.230108s partition=IdentityCachePartition(1)
```
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Update MSRV to 1.74
## Description
Normal slate of things, mostly appeasing clippy.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
For context, see
https://github.com/smithy-lang/smithy-rs/discussions/3408
## Description
<!--- Describe your changes in detail -->
- During `invoke`, load all timeout configs and merge them via a custom
loader.
- Fix config bag bugs that prevented using a Stored type that differed
from `T`.
- Add new e2e and codegen integration test validating that timeout
settings are properly merged.
- Add fallback for an empty timeout config being equivalent to
`TimeoutConfig::disabled`.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Description
Via code inspection, we have identified that there is a potential bug in
`DEFAULT_BUFFER_TIME_JITTER_FRACTION`. Specifically, if the fraction
happens to be set to 1.0, we end up not respecting the buffer time for
cache refresh (see diagrams in #2335). This PR will cap the max fraction
value to 0.5 to avoid the problem.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
#3322
## Description
<!--- Describe your changes in detail -->
I gave classifiers priorities but never actually sorted them. This PR
fixes that.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
I wrote a test
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Motivation and Context
This enables the following code:
```rust
let req = client
.get_object()
.bucket("foo")
.key("bar")
.customize()
.mutate_request(|req| {
req.set_uri(req.uri().to_string() + "&a=b")
.expect("failed to update URI")
})
.presigned(static_ps_config)
.await
```
Previously, it wasn't possible to presign a request once customization
had begun.
## Description
- Follow the same pattern as send by introducing an additional trait,
CustomizeablePresign
- change InvokeWithStopPoint to actually _return_ the error if there is
one.
## Testing
New integration test
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
- [x] Conditionally generate the presign method
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
- aws-sdk-rust#977
- smithy-rs#3365
## Description
Add `try_from` and `try_into` for HTTP 1.x to the HTTP request/response
wrapper. This is a stepping stone en route to supporting Hyper 1.0
## Testing
- [x] New unit tests
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
Defer fixing the event stream semver hazard.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
We intend to include aws-smithy-mocks-experimental in the release, but
it needs to be added to the CrateSet to actually be published.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Russell Cohen <rcoh@amazon.com>
This PR sets independent versions for the deprecated runtime crates so
that they won't publish new version numbers with every release anymore.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
- aws-sdk-rust#901
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
## Description
Identity resolvers aren't a list—they are a map keyed on AuthSchemeId.
This updates the internal representation to match.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
When we released smithy-rs release-2023-12-08, we introduced a silent
failure for endpoint prefixes, and not in the newly released version,
but in the previous releases. There is a subtle issue with semver that
causes this. This PR addresses the endpoint prefix part of this problem.
Other PRs will fix other parts that are broken by this semver issue.
The issue is that unstable (0.x) runtime crates are declaring types that
get placed into the `ConfigBag`, and these types are referenced in the
`ConfigBag` across crate boundaries. This by itself isn't a problem, but
because our stable 1.x crates depend on the unstable crates, it becomes
a problem. By releasing 1.1.0 that depends on 0.61, consumers of 1.x
pull in both 0.60 and 0.61. The generated code pulls in 0.60, and the
1.1.x crates pull in 0.61. This is fine since two semver-incompatible
crate versions can be in the dependency closure. Thus, the generated
code which is using 0.60 is placing a 0.60 type in the `ConfigBag`, and
the runtime crates that pull the type out of the `ConfigBag` are
expecting a 0.61 version of it. This leads to the type not existing upon
lookup, which then causes the silent break.
This PR fixes this by moving the `EndpointPrefix` type and its
associated methods into `aws-smithy-runtime-api`, a stable crate. The
`aws-smithy-http` unstable crate is updated to point to the new stable
version so that a patch release of that crate will solve the issue for
old versions going forward as well.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This issue addresses a semver compatibility problem similar to the one
described in #3318, except for the
`aws_smithy_http::operation::Metadata` type.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Publishing is disabled for this package currently.
## Motivation and Context
Testing is a huge pain. Currently. This method isn't ideal and can lack
accuracy in some cases but in quick and useful for many applications.
## Description
New mock package that allows code like this:
```rust
let s3_404 = mock!(Client::get_object)
.match_requests(|inp| {
inp.bucket() == Some("test-bucket") && inp.key() != Some("correct-key")
})
.then_http_response(|| {
http::Response::builder()
.status(400)
.body(SdkBody::from(S3_NO_SUCH_KEY))
.unwrap()
.try_into()
.unwrap()
});
let s3_real_object = mock!(Client::get_object)
.match_requests(|inp| {
inp.bucket() == Some("test-bucket") && inp.key() == Some("correct-key")
})
.then_output(|| {
GetObjectOutput::builder()
.body(ByteStream::from_static(b"test-test-test"))
.build()
});
let get_object_mocks = MockResponseInterceptor::new()
.with_rule(&s3_404)
.with_rule(&s3_real_object);
let s3 = aws_sdk_s3::Client::from_conf(
Config::builder()
.with_test_defaults()
.region(Region::new("us-east-1"))
.interceptor(get_object_mocks)
.build(),
);
```
There is no binary level mocking and this is completely typesafe. IDE
inference works properly as well. The crimes that were committed were
small and self-contained.
## Testing
There is a unit test and it works.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Address #3356
## Motivation and Context
Solves compilation error mentioned in #3356
## Description
Qualify access to `base64` module
## Testing
Trivial compilation changes has been done - `cargo build` succeeds with
this change, while it doesn't without it. Provided of course that
`aws_sdk_unstable` config is selected and `serde-serialize` feature is
enabled.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
aws-sdk-rust#1010
## Description
Add `as-service-error` helper function to cleanup handling of service
error
## Testing
UT
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
https://github.com/awslabs/aws-sdk-rust/discussions/995
## Description
I tried to implement futures::Stream for a wrapper struct around
`PaginationStream`. I am unsure if I did it in the best way. After
fighting with the borrow checker for a while I decided to try
`Arc<Mutex<_>>` - is this the way to go or does there exist a better
way?
Even then, does the code look correct? I used it in my project and my
integration tests do pass but I am not 100% that these tests will catch
any error in paginated ListObjectsV2.
I would appreciate any feedback so far.
## Testing
In progress while waiting for feedback on code
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Russell Cohen <rcoh@amazon.com>
Co-authored-by: Russell Cohen <russell.r.cohen@gmail.com>
## Motivation and Context
This is a sub-PR of https://github.com/awslabs/smithy-rs/pull/2615.
Refactors `blob.rs` file.
## Description
Some test was failing due to unnecessary import; This PR fixes it.
## Testing
NA
## Checklist
NA
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Zelda Hessler <zhessler@amazon.com>
## Motivation and Context
Extracted from #3308, this adds doc example scraping. This won't make
much of a difference yet but it will help if we're able to move example
repos directly under the SDKs themselves when appropriate.
## Description
https://doc.rust-lang.org/rustdoc/scraped-examples.html
## Testing
verified that examples appear in docs when expected
## Checklist
no changelog
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Showcase how to pass TLS derived information to server operation
handlers, like the certificate chain presented by the client.
To test, run `RUST_LOG=pokemon_service_tls=DEBUG cargo run` and `curl -v
--insecure https://localhost:13734/do-nothing`. Alternatively, run the
tests using `RUST_LOG=pokemon_service_tls=DEBUG cargo test`, which have
been updated to hit the operation that logs the TLS connection derived
information.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
When using JDK 20, the following error would occur when attempting to
build or run tests:
```
Execution failed for task ':codegen-client:compileKotlin'.
> Inconsistent JVM-target compatibility detected for tasks 'compileJava' (20) and 'compileKotlin' (11).
```
This PR explicitly sets the Java source and target versions to fix this
error.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: ysaito1001 <awsaito@amazon.com>
## Motivation and Context
- aws-sdk-rust#977
## Description
The first of several PRs to make add support for Hyper 1.0. This minimal
change allows the use of Hyper 1.0 bodies although it does not actually
leverage Hyper 1.0.
## Testing
- Unit test suite
- Ran cargo hack check --feature-powerset because we had a lot of
features. I found a couple of issues.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Some APIs return JSON values that are intended to be represented by
integral types but are returned as floating values e.g `[1.0, -2.0,
25.0]`.
This allows those values to be converted into Integral types.
## Description
This uses a bidirectional conversion to check if a float can be
losslessly converted into a integral type. This can have issues at the
limits of i64::MAX but I think that's probably acceptable. These values
would be represented imprecisely by floats already.
## Testing
Added additional unit tests of the behavior.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Fix deprecation warnings in the gradle build scripts, and upgrade jsoup
and gson.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: ysaito1001 <awsaito@amazon.com>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Motivation and Context
I want to use this field to uniquely identify TCP connection based on
their `local_addr` + `remote_addr`.
See https://github.com/awslabs/aws-sdk-rust/issues/990 for additional
motivation for this change.
## Description
- Add a new optional `local_addr` field in the `ConnectionMetadata`
struct.
- Transfer the `local_addr` `SocketAddress` from the `hyper::HttpInfo`
to the `ConnectionMetadata` field.
- Add to the `trace-serialize` example program so that it will print out
the capture connection values.
## Testing
`cargo test` in `rust-runtime/aws-smithy-runtime-api` and
`aws-smithy-runtime`.
Also ran:
```
thedeck@c889f3b04fb0 examples % cargo run --example trace-serialize
Finished dev [unoptimized + debuginfo] target(s) in 0.13s
Running `/Users/thedeck/repos/github/declanvk/smithy-rs/target/debug/examples/trace-serialize`
2023-12-06T00:13:15.605555Z INFO lazy_load_identity: aws_smithy_runtime::client::identity::cache::lazy: identity cache miss occurred; added new identity (took Ok(296µs))
2023-12-06T00:13:15.608344Z INFO trace_serialize: Response received: response=Response { status: StatusCode(200), headers: Headers { headers: {"content-type": HeaderValue { _private: "application/json" }, "content-length": HeaderValue { _private: "17" }, "date": HeaderValue { _private: "Wed, 06 Dec 2023 00:13:15 GMT" }} }, body: SdkBody { inner: BoxBody, retryable: false }, extensions: Extensions }
2023-12-06T00:13:15.608388Z INFO trace_serialize: Captured connection info remote_addr=Some(127.0.0.1:13734) local_addr=Some(127.0.0.1:50199)
2023-12-06T00:13:15.608511Z INFO trace_serialize: Response received POKEMON_SERVICE_URL=http://localhost:13734 response=GetServerStatisticsOutput { calls_count: 0 }
```
You can see the log line with "Captured connection info" contains the
`remote_addr` and the `local_addr` fields.
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Co-authored-by: Declan Kelly <thedeck@amazon.com>
Fix broken links as a result of repo movement
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Moves the doc comments from HyperConnector to HyperClientBuilder where
they're more relevant, and fixes the examples.
This fix is for https://github.com/awslabs/aws-sdk-rust/issues/986.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This patch adds a stack-allocated list of explored auth schemes and the
reason each didn't work to the auth orchestrator so that its error
message is much easier to decipher.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Fixes https://github.com/awslabs/aws-sdk-rust/issues/973
## Description
Prior to the PR, if a customer explicitly passed a credentials provider
to a client's config `Builder::set_credentials_provider`, what's passed
did not override a credentials provider previously set ([actual use
case](https://github.com/awslabs/aws-sdk-rust/issues/973#issuecomment-1827224049)).
While in general, we recommend customers single-source a credentials
provider through
[aws_config::ConfigLoader::credentials_provider](https://docs.rs/aws-config/1.0.1/aws_config/struct.ConfigLoader.html#method.credentials_provider),
we should eliminate the said footgun in case they directly pass a
credentials provider to a client's config `Builder`.
The PR reverts test signature updates in
https://github.com/smithy-lang/smithy-rs/pull/3156 (in hindsight, having
to update test signatures in that PR was a sign of regression).
## Testing
Added a Kotlin test to `CredentialProviderConfigTest.kt` to verify the
fix
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
This change initializes the TLS trust certs at base client validation
time rather than upon creation of the default HTTP client runtime plugin
so that if the default is overridden, that initialization doesn't need
to take place. This is especially helpful on MacOS where that
initialization takes approximately 100 milliseconds.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Russell Cohen <rcoh@amazon.com>
Each client initialization was taking between 1 and 2 milliseconds,
regardless if the client had been constructed before or not. For
example, if a customer wants five clients with different credentials
providers, that could be 10 milliseconds of time spent in
`Client::from_conf`. Approximately 98% of this time was spent compiling
regular expressions for the endpoint partition resolver.
This change switches everything over to the regex-lite crate, which has
faster regex compile times, and shouldn't have much of an impact on
performance for our specific use-cases (small strings, only evaluated at
client initialization).
The use of regex was entirely removed in aws-sigv4 since it was overkill
for what it was being used for.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
The original PR was accidentally removed in a bad merge.
## Testing
- Exact changes from original PR
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
An incorrect regex prevented `--` from being used in a bucket name
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
A number of small issues in StalledStreamDetection came together to make
it ineffective in practice:
1. We didn't push a throughput `0` on `Poll::Pending`. This means that
if the stream goes to poll pending, the calculate throughput can never
get to 0.
2. Because we always considered the _entire_ throughput log, an actually
stalled stream creates a pathological case where most of the log is full
of fast moving data, but we are very slow to evict it and detect
slowness. With a 426 length log, it would effectively take 7 minutes for
it to actually get to 0.
For these two issues, I introduced a check-window (default 1 second) in
the throughput log. We only consider this much data when making the
calculation. To avoid undeseriable interactions with the check interval,
I reduced the check interval to 500ms. I think this is likely to be
better in practice at detecting stalled streams.
As a coincidence, this makes all the math exact so the tests are now
precise without floating epsilons.
Finally, in an unrelated issue, the `check_interval` wasn't actually
being used in the call to sleep, I fixed that as well and added a test.
In doing this, I tried to also simplify sine wave test into a test that
could be logically reasoned about. The previous test was producing
nonsense data (integer input to `sine` which is in radians as one
example). I replaced it with several tests that send data at one rate,
then suddenly stop sending data, simulating a stalled stream. These have
the nice property that it's easy to determine mathematically when the
stream should stall.
Side note: It's possible these bugs are what was making it not work for
request bodies? Needs more investigation. I didn't rerun that test.
After those issues were resolved, I was a little concerned about
performance when maxing out the network connection. A quick benchmark
showed there was a small regression. When data is flowing normally, the
426 item buffer is usually shorter than our default check window of 1
second. This allows for an optimization where we track the current total
amount of data in the buffer, allowing us to return the calculated
throughput in constant time.
During writing of the test, I discovered that we didn't actually expose
`Throughput` so I took that as an opportunity to change it to use `u64`
instead of `f64` for it's byte count representation.
## Testing
- [x] Manual test of downloading a file then turning off the wifi.
Verify that the connection is aborted within the grace period.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Without this, we will have http = 0.2 permanently in-tree.
## Description
- Add feature gate for http 02x.
- ~Add http 1x as an experiment.~
## Testing
CI
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Caymon Sullivan