Fixes: #3471
## Motivation and Context
An issue was raised about a mobile client that appends "; charset=utf-8"
to the Content-Type when using restJson1. The [latest
RFC](https://www.rfc-editor.org/rfc/rfc8259) for "application/json" does
not register a charset parameter, but indicates it is reasonable to
accept it.
## Description
This change loosens the validation of the expected content type to allow
all parameters.
## Testing
* Tests for each protocol were added to
[smithy](https://github.com/smithy-lang/smithy/pull/2296)
* ran the runtime and codegen tests
* Added test for rest-xml, as smithy-rs does not currently run the
smithy 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._
## Motivation and Context
The generated SDK conditionally re-exports `routing::LambdaHandler`
under the feature flag aws-lambda, but the `Cargo.toml` does not define
such a feature.
## Description
Closes: https://github.com/smithy-lang/smithy-rs/issues/3643
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
Co-authored-by: david-perez <d@vidp.dev>
This fixes two bugs:
1. `Content-Type` header checking was succeeding when no `Content-Type`
header was present but one was expected.
2. When a shape was `@httpPayload`-bound, `Content-Type` header checking
occurred even when no payload was being sent. In this case it is not
necessary to check the header, since there is no content.
Code has been refactored and cleaned up. The crux of the logic is now
easier to understand, and contained in `content_type_header_classifier`.
## 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._
## Motivation and Context
https://github.com/awslabs/aws-sdk-rust/issues/1163
## Description
When the S3 SDK processes a response with the 200 status code but with
`InternalError`, the SDK today does not trigger a retry through any
classifier in the chain: `AwsErrorCodeClassifier`,
`ModeledAsRetryableClassifier`, `HttpStatusCodeClassifier`, and
`TransientErrorClassifier`. To address it, this PR updates
`AwsErrorCodeClassifier` only for S3 so that it classifies
`InternalError` as retryable.
## Testing
- [x] CI
- [x] Added traced test to the existing test file `status-200-errors.rs`
## 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._
## 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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
aws-sdk-rust#1166
## Description
<!--- Describe your changes in detail -->
SSP shouldn't be enabled for long-running operations that transfer no
data.
## 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. -->
Checked the generated lambda SDK to see that SSP has been disabled for
the operations specified.
## 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
aws-sdk-rust#1162
## Testing
Tests in CI
## 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._
The Server README had a stale warning:
```
** This is a work in progress and generates serialization/de-serialization code that is probably unusable for the time being. ```
---------
Co-authored-by: Fahad Zubair <fahadzub@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 -->
The paginator for the S3 `ListParts` operation could loop forever:
https://github.com/awslabs/aws-sdk-rust/issues/1143. This is because
most paginated operations use an empty next token as an indication that
pagination is exhausted. `ListParts` instead sets the final next token
as `0` causing the pagination to loop back to the first page and loop
forever. Instead of an empty next token `ListParts` uses `IsTruncated =
false` to indicate that pagination has been exhausted.
## Description
<!--- Describe your changes in detail -->
* Added a new trait `isTruncatedPaginatorTrait`
* Add that trait to the S3 `ListPartsOutput` shape
* Use the presence of that trait to vary the logic setting the
`is_empty` value in the paginator.
* If the trait is absent it looks for an empty next token as always
* if the trait is present the value is set based on the value of the
response's `is_truncated` field
## 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. -->
* Added integration test confirming that pagination terminates when a
response contains `is_truncated = false`
**Note:** I'm still working on turning this into a model test rather
than an S3 specific integration test, but I wanted to get some feedback
on the actual fix while I'm figuring that out)
## 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
<!--- Why is this change required? What problem does it solve? -->
Making this conversion bidirectional is helpful.
<!--- If it fixes an open issue, please link to the issue here -->
## Description
<!--- Describe your changes in detail -->
Add `impl From<StatusCode> for httpN::StatusCode` that does the obvious
thing.
## 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'm using these conversions in my own project. As all three crates have
identical constraints on the status code value the changes are trivially
correct.
## 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
Not clear to me what if anything to do here.
----
_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
Rustc 1.74.0 removed the private-in-public check, which raises a
compile-time error if a member of a struct has a type which is less
visible than the parent struct. Fixing this private-in-public issue
enables aws-smithy-runtime to build in projects using rustc older than
1.74.0.
## Description
Make UploadThroughputCheckFuture pub(crate) because it is needed in
MaybeUploadThroughputCheckFuture which is pub(crate).
## Testing
Verified that crate now compiles using rustc 1.72.1.
## 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: ysaito1001 <awsaito@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 -->
#1925
## Description
<!--- Describe your changes in detail -->
Implements the v1 `http_body::Body` trait for `PathBody`. Part of the
ongoing hyper v1 upgrade.
This also moves a pre-1.0 impl into its own module.
## 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 ported the tests too
## 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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Our logs had several entries that were extremely verbose and made them
harder to sort through. This change aims to reduce the verbosity of
those logs to something more manageable.
## Description
<!--- Describe your changes in detail -->
- Removed the logging of the full IMDS Client struct, replaced with a
message that it was truncated
- Removed logging the full `Configbag` in a couple places in
`RuntimeComponentsBuilder`
- Removed logging of full `ProvideCredentials` objects in the
CredentialsProviderChain` and replaced with just their names
There are some verbose logs I did not remove because I was not sure of
their usefulness. Most notably the `PartitionResolver` struct logs
several hundred lines of region information each time it appears. Happy
to truncate that as well if those logs aren't too helpful.
## 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 was tested locally by running the SDK [logging
example](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/logging.html)
code with `RUST_LOG=trace` prepended to the `cargo run` command. For
comparison, when saved as a .txt file, the old logs take up `2.8MB` and
the new logs take `273KB` for the same operation.
## 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._
_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>
Co-authored-by: ysaito1001 <awsaito@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 -->
* https://github.com/awslabs/aws-sdk-rust/issues/1141
* https://github.com/awslabs/aws-sdk-rust/issues/1146
* https://github.com/awslabs/aws-sdk-rust/issues/1148
## Description
* Disables stalled stream upload protection for requests with an
empty/zero length body.
* Disables stalled stream upload throughput checking once the request
body has been read and handed off to the HTTP layer.
## Testing
Additional integration tests added covering empty bodies and completed
uploads.
Tested SQS issue against latest runtime and can see it works now. The S3
`CopyObject` issue is related to downloads and will need a different
solution.
## 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: Zelda Hessler <zhessler@amazon.com>
Co-authored-by: ysaito1001 <awsaito@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 -->
Docs indicating that the `AppName` can be loaded from an environment
variable or profile key were buried in the default provider and would be
hard to find for users.
## Description
<!--- Describe your changes in detail -->
This change adds documentation to the `app_name` method on
`ConfigLoader` that makes the options for loading the `AppName` more
explicit.
## 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. -->
Ran `cargo doc` to ensure the docs were generated correctly
## 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: ysaito1001 <awsaito@amazon.com>
## Motivation and Context
Avoids panic when [Duration for exponential
backoff](https://github.com/smithy-lang/smithy-rs/blob/main/rust-runtime/aws-smithy-runtime/src/client/retries/strategy/standard.rs#L150)
could not be created from a large float.
## Description
[Duration::from_secs_f64](https://doc.rust-lang.org/core/time/struct.Duration.html#method.from_secs_f64)
may panic. This PR switches to use a fallible sibling
`Duration::try_from_secs_f64` to avoid panics. If
`Duration::try_from_secs_f64` returns an `Err` we fallback to
`max_backoff` for subsequent retries. Furthermore, we learned from
internal discussion that jitter also needs to be applied to
`max_backoff`. This PR updates `calculate_exponential_backoff` to handle
all the said business logic in one place.
## Testing
- Added a unit test
`should_not_panic_when_exponential_backoff_duration_could_not_be_created`
- Manually verified reproduction steps provided [in the original
PR](https://github.com/awslabs/aws-sdk-rust/issues/1133)
<details>
<summary>More details</summary>
```
#[tokio::test]
async fn repro_1133() {
let config = aws_config::from_env()
.region(Region::new("non-existing-region")) // forces retries
.retry_config(
RetryConfig::standard()
.with_initial_backoff(Duration::from_millis(1))
.with_max_attempts(100),
)
.timeout_config(
TimeoutConfig::builder()
.operation_attempt_timeout(Duration::from_secs(180))
.operation_timeout(Duration::from_secs(600))
.build(),
)
.load()
.await;
let client: Client = Client::new(&config);
let res = client
.list_objects_v2()
.bucket("bucket-name-does-not-matter")
.send()
.await;
dbg!(res);
}
```
Without changes in this PR:
```
---- repro_1133 stdout ----
thread 'repro_1133' panicked at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/time.rs:741:23:
can not convert float seconds to Duration: value is either too big or NaN
stack backtrace:
...
failures:
repro_1133
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 9 filtered out; finished in 338.18s
```
With changes in this PR:
```
// no panic
---- repro_1133 stdout ----
res = Err(
TimeoutError(
TimeoutError {
source: MaybeTimeoutError {
kind: Operation,
duration: 600s,
},
},
),
)
```
</details>
## 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
## Appendix
<details>
<summary>runtime-versioner bug fix</summary>
This PR also fixes a limitation in `runtime-versioner audit`. I included
the fix in the PR because the issue occurred with special conditions,
and we don't get to reproduce it every day. The way the issue manifests
is this.
1. We have a branch from the main whose latest release tag at the time
was `release-2024-04-30`
2. The main has moved ahead and a new `smithy-rs` release has been made
`release-2024-05-08`
3. We perform `git merge main`, pre-commit hooks run, and we then get
`audit` failures from `runtime-versioner`:
```
2024-05-10T16:54:36.434968Z WARN runtime_versioner::command::audit: there are newer releases since 'release-2024-04-30'
aws-config was changed and version bumped, but the new version number (1.4.0) has already been published to crates.io. Choose a new version number.
aws-runtime was changed and version bumped, but the new version number (1.2.2) has already been published to crates.io. Choose a new version number.
aws-smithy-runtime-api was changed and version bumped, but the new version number (1.6.0) has already been published to crates.io. Choose a new version number.
aws-smithy-types was changed and version bumped, but the new version number (1.1.9) has already been published to crates.io. Choose a new version number.
aws-types was changed and version bumped, but the new version number (1.2.1) has already been published to crates.io. Choose a new version number.
Error: there are audit failures in the runtime crates
```
This happens because when the latest `main` is being merged to our
branch, `runtime-versioner audit` should use `previous_release_tag`
`release-2024-05-08` to perform audit but [pre-commit hooks run the
tool](https://github.com/smithy-lang/smithy-rs/blob/main/.pre-commit-hooks/runtime-versioner.sh#L8)
using the latest previous release tag that can be traced back from
`HEAD` of our branch, which is `release-2024-04-30`. Hence the error.
The fix adds an environment variable
`SMITHY_RS_RUNTIME_VERSIONER_AUDIT_PREVIOUS_RELEASE_TAG` to specify a
previous release tag override, in addition to a `--previous-release-tag`
command-line argument.
Furthermore, the fix has relaxed certain checks in `audit`. Taking our
example for instance, when `HEAD` is now behind `release-2024-05-08`,
it's OK to fail even if `release-2024-05-08` is not the ancestor of
`HEAD` (as stated above, `git merge-base --is-ancestor` does not know
that while main is being merged) as long as `release-2024-04-28` (the
latest release seen from `HEAD`) is the ancestor of
`release-2024-05-08`.
```
release-2024-04-28 release-2024-05-08
│ │
────────────┼───────────────┬────────────────┼───────x─────► main
│ │HEAD │ x
│ of x
│branch x
│ x
│ x
│ xxxxxxxxxxx
│ x
│ x git merge main
│ x
│ ▼
│
└──────────────────► feature branch
```
To use the fix, set the environment variable with the new release tag
and perform `git merge main`:
```
➜ smithy-rs git:(ysaito/fix-panic-in-exp-backoff) ✗ export SMITHY_RS_RUNTIME_VERSIONER_AUDIT_PREVIOUS_RELEASE_TAG=release-2024-05-08
➜ smithy-rs git:(ysaito/fix-panic-in-exp-backoff) ✗ git merge main
...
Running `/Users/awsaito/src/smithy-rs/tools/target/debug/runtime-versioner audit`
2024-05-10T19:32:26.665578Z WARN runtime_versioner::tag: expected previous release to be 'release-2024-04-30', but 'release-2024-05-08' was specified. Proceeding with 'release-2024-05-08'.
SUCCESS
```
</summary>
----
_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
This PR is the combination of two previously reviewed PRs that both
enable new behaviors behind a new Behavior Major Version (BMV):
* https://github.com/smithy-lang/smithy-rs/pull/3527
* https://github.com/smithy-lang/smithy-rs/pull/3578
## Description
* Enables stalled stream protection by default on latest behavior
version.
* Enables creation of a default identity cache.
## Testing
All testing done on prior PRs. See for details.
## 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>
Co-authored-by: ysaito1001 <awsaito@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
According to #3161 , the Debug output was in a marginally legible
format.
<!--- If it fixes an open issue, please link to the issue here -->
#3161
## Description
<!--- Describe your changes in detail -->
Since there's no expected difference between `Debug` and `Display` for
date_time, the `fmt::Debug` for `date_time` calls the already
implemented `Display`.
## Testing
<!--- Please describe in detail how you tested your changes -->
I added unit tests, and ran `cargo test` within the `rust-runtime`
directory.
<!--- Include details of your testing environment, and the tests you ran
to -->
Aarch64 mac terminal - `$ cd rust-runtime && cargo test`
<!--- see how your change affects other areas of the code, etc. -->
A single test failed:
`client::waiters::backoff::tests::backoff_with_seeded_jitter` at first.
After rebasing on upstream, the failure went away. Thanks for 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
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: Mike Nissenbaum <mnissenb@amazon.com>
Addresses https://github.com/awslabs/aws-sdk-rust/issues/879
----
_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>
Event stream operations with struct shaped messages were using the wrong
`:content-type` message header value, which I think wasn't caught before
since the supported AWS S3/Transcribe event stream operations don't
serialize struct messages. This PR fixes the message content type
serialization.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This PR sets the `rust-version` property on generated Cargo.toml files
for the AWS SDK crates. It doesn't attempt to place the property on the
runtime crates for now since that will either require manual updating,
or more machinery to automate.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This PR implements waiters according to the [Smithy waiters
spec](https://smithy.io/2.0/additional-specs/waiters.html).
----
_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
Each constrained shape has an associated `ConstraintViolation`
structure, which at the moment does not implement `std::error::Error`.
## Description
All of the `ConstraintViolation` structures now implements
`std::fmt::Display` and the `std::error::Error` marker trait. There is a
difference between the message used for `pub(crate) fn
as_validation_exception_field` and for `std::fmt::Display` as the latter
does not know of the particular field which is being set in the
structure. Hence, it uses the shape ID instead.
For example, for a constrained `int`, the following is the message used
in `Display`:
```
write!(f, "Value for `com.aws.example#MyNumberSensitive`failed to satisfy constraint: Member must be greater than or equal to 100")
```
and the following is used for `as_validation_exception_field`:
```
format!("Value at '{}' failed to satisfy constraint: Member must be greater than or equal to 100", &path),
```
## Testing
Tests have been added to ensure:
1. `std::fmt::Display` has all of the variants for the enum that
represents the associated `Error` type in the `ConstraintViolation`
struct.
2. `ConstraintViolation` implements `std::error::Error`.
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
## Motivation and Context
Running `cargo build --target wasm32-unknown-unknown
--no-default-features` on an S3 crate has stopped working since
https://github.com/smithy-lang/smithy-rs/pull/3465 with the following
error:
```
error: the wasm*-unknown-unknown targets are not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
--> /Users/[REDACTED]/.cargo/registry/src/index.crates.io-6f17d22bba15001f/getrandom-0.2.14/src/lib.rs:352:9
|
352 | / compile_error!("the wasm*-unknown-unknown targets are not supported by \
353 | | default, you may need to enable the \"js\" feature. \
354 | | For more information see: \
355 | | https://docs.rs/getrandom/#webassembly-support");
| |________________________________________________________________________^
```
To address the issue, this PR updates an S3's dependency on `ahash` in a
way that disables default features.
## Testing
Updated the existing test `integration-tests/webassembly` so that
`check-aws-sdk-standalone-integration-tests` will run `cargo check`
`aws-sdk-s3` against both `wasm32-wasi` and `wasm32-unknown-unknown`
(the updated check would break if we removed `default-features = false`
from the `ahash` dependency).
## 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._
Resolves#3533
`SigningSettings` and some of its fields didn't implement
`Clone`/`Copy`, even though they could. This made it cumbersome to store
and re-use a value of `SigningSettings`.
----
_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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Original issue: https://github.com/smithy-lang/smithy-rs/issues/3427
RFC: https://github.com/smithy-lang/smithy-rs/pull/3544
## Description
<!--- Describe your changes in detail -->
Fixes the `SharedCredentialsProvider` and `SharedTokenProvider` to
re-use a consistent cache partition by default.
`SdkConfig` does not create an identity cache by default still, that
will need to be a follow on PR that gates it behind a new behavior
version. Ideally we do that with the stalled stream protection work in
https://github.com/smithy-lang/smithy-rs/pull/3527
## 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. -->
Added new unit and integration 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
----
_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
Unions that have a [unit target member
shape](https://smithy.io/2.0/spec/model.html#unit-type) do not have an
associated data in the generated Rust enum.
Closes Issue:
[2546](https://github.com/smithy-lang/smithy-rs/issues/2546)
## Description
On the **server** side, when the union has constrained members, the code
generated for the conversion from the `Unconstrained` type to the
`Constrained` type incorrectly assumed that each Rust enum would have
associated data.
```
rust-server-codegen/src/unconstrained.rs:31:129
|
| crate::unconstrained::some_union_with_unit_unconstrained::SomeUnionWithUnitUnconstrained::Option1(unconstrained) => Self::Option1(
| -^^^^^^^^^^^^- help: consider using a semicolon here to finish the statement: `;`
| _________________________________________________________________________________________________________________________________|
| |
| | unconstrained
| | ),
| |_____________- call expression requires function
|
::: rust-server-codegen/src/model.rs:152:5
|
| Option1,
| ------- `SomeUnionWithUnit::Option1` defined here
```
The marshaling code for event streams with unit target types incorrectly
assumed that the variant would have associated data.
```
rust-server-codegen/src/event_stream_serde.rs
impl ::aws_smithy_eventstream::frame::MarshallMessage for TestEventMarshaller {
fn marshal() {
let payload = match input {
Self::Input::KeepAlive(inner) => {
```
On the **client** side, the `event_stream_serde` code incorrectly
assumes that a union member, which has the `@streaming` trait applied to
it, takes a `model::Unit` type.
```
rust-client-codegen/src/event_stream_serde.rs:
|
| crate::types::TestEvent::KeepAlive(crate::types::Unit::builder().build()),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^---------------------------------------
| |
| call expression requires function
|
::: rust-client-codegen/src/types/_test_event.rs
|
| KeepAlive,
| --------- `TestEvent::KeepAlive` defined here
```
## Testing
A unit test has been added that tests the following model:
```
$version: "2"
namespace com.example
use aws.protocols#restJson1
use smithy.framework#ValidationException
@restJson1 @title("Test Service")
service TestService {
version: "0.1",
operations: [
TestOperation
TestSimpleUnionWithUnit
]
}
@http(uri: "/testunit", method: "POST")
operation TestSimpleUnionWithUnit {
input := {
@required
request: SomeUnionWithUnit
}
output := {
result : SomeUnionWithUnit
}
errors: [
ValidationException
]
}
@length(min: 13)
string StringRestricted
union SomeUnionWithUnit {
Option1: Unit
Option2: StringRestricted
}
@http(uri: "/test", method: "POST")
operation TestOperation {
input := { payload: String }
output := {
@httpPayload
events: TestEvent
},
errors: [ValidationException]
}
@streaming
union TestEvent {
KeepAlive: Unit,
Response: TestResponseEvent,
}
structure TestResponseEvent {
data: String
}
```
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
This commit unreverts 27834ae2cc (#3485).
Original commit message:
Overhaul stalled stream protection and add upload support (#3485)
This PR overhauls the existing stalled stream protection with a new
algorithm, and also adds support for minimum throughput on upload
streams. The new algorithm adds support for differentiating between the
user or the server causing the stall, and not timing out if it's the
user causing the stall. This will fix timeout issues when a customer
makes remote service calls in between streaming pieces of information.
## 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 -->
https://github.com/awsdocs/aws-doc-sdk-examples/pull/6021
## Description
<!--- Describe your changes in detail -->
This change makes it possible to retry requests that were successfully
deserialized into an output.
## 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
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._
Dj