## 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 -->
At some point in the near future (after this customization is applied to
all existing SDKs) the S3 model will change the type of `Expires`
members to `String` from the current `Timestamp`. This change would
break backwards compatibility for us.
## Description
<!--- Describe your changes in detail -->
Add customization to ensure S3 `Expires` field is always a `Timestamp`
and ass a new synthetic member `ExpiresString` that persists the
un-parsed data from the `Expires` header.
## 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 tests to ensure that the model is pre-processed correctly. Added
integration tests for S3. Considered making this more generic codegen
tests, but since this customization will almost certainly only ever
apply to S3 and I wanted to ensure that it was properly applied to the
generated S3 SDK I opted for this route.
## 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._
Updates the smithy-rs models to the latest versions.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
We currently "hotfix" a broken protocol test in-memory, but there's no
mechanism that alerts us when the broken protocol test has been fixed
upstream when updating our Smithy version. This commit introduces such a
mechanism by generating both the original and the fixed test, with a
`#[should_panic]` attribute on the former, so that the test fails when
all its assertions succeed.
With this change, in general this approach of fixing tests in-memory
should now be used over adding the broken test to `expectFail` and
adding the fixed test to a `<protocol>-extras.smithy` Smithy model,
which is substantially more effort.
----
_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
Docs are wrong.
## Description
The docs are referring to the wrong type name (`Config`).
The example right below the change uses the right type name
(`$crateName::config::Builder`).
## Testing
n/a
## Checklist
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
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._
Refactor and define a separate function that returns a set of operation
shapes that must have a supported validation exception shape in their
associated errors list.
This helps identify which type of `ValidationException` has been added
to the operation shape's errors list.
Closes: [3722](https://github.com/smithy-lang/smithy-rs/issues/3722)
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
Co-authored-by: david-perez <d@vidp.dev>
Protocol test generation code was one of the earlier parts of
smithy-rs's codebase and it has accrued a fair amount of tech debt as we
have evolved the code generation primitives. Its code was also forked
when the server code generator was introduced, introducing a lot of
duplicated code that has deviated over time.
This commit refactors the code to modern standards and aims to reconcile
commonalities in `ProtocolTestGenerator`, so that both client and server
can reap centralized improvements over time.
----
_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 refactors the code to limit the visibility of
`crate::model::ValidationExceptionField` to only those decorators and
associated classes that are invoked when
`smithy.framework#ValidationException` is being used.
More information is in [this
issue](https://github.com/smithy-lang/smithy-rs/issues/3718).
Closes: [3178](https://github.com/smithy-lang/smithy-rs/issues/3718)
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
Co-authored-by: david-perez <d@vidp.dev>
to get the path of the top level of the repo
## 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 -->
Fixing issue with test workspaces that would break if the repo is not
named `smithy-rs`
## Description
<!--- Describe your changes in detail -->
Moved to using `git rev-parse --show-toplevel` to get the project
directory instead of climbing the file tree.
## 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. -->
All of our CI tests this since it is part of generating test workspaces
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Also fixes IntelliJ lints
This PR is not intended to change any behavior. If you see me doing that
somewhere, then it's a mistake.
----
_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 -->
Due to numerous dependency issues over the past few weeks several of our
dependencies were pinned to specific minor versions. Now that we have
lockfiles for all of our workspaces those pinned versions can be undone.
## Description
<!--- Describe your changes in detail -->
I unpinned those dependencies and generated new lockfiles after that
change.
## 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 ran the gradle `assemble` and `sdkTest` tasks locally and they both
passed. I ran a full set of preview/release e2e tests against this
change in my local stack and those all passed. And since we copy the
Cargo.lock into the test workspaces the CI run for this PR will also
test the changes.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
No functional changes, only dependency changes.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Otherwise, if you generate a crate and compile it using Gradle, like for
example using the invocation:
```
./gradlew -P modules='simple' -P cargoCommands='test' codegen-server-test:build
```
And then manually run a `cargo` command within the generated crate
directory, or open the project using `rust-analyzer`, Cargo will
re-compile the project from scratch, with
`CARGO_LOG=cargo::core::compiler::fingerprint=trace` reporting that
flags have changed since the last compilation.
Instead, it's best if we persist these flags to `.cargo/config.toml`, so
all `cargo` invocations, either through Gradle, manually, or through
`rust-analyzer`, use the same set. This way, if no files were changed,
subsequent compilations since code generation will truly be no-ops, with
Cargo reusing all artifacts.
Note this commit fixes a regression that was introduced when `--cfg
aws_sdk_unstable` was introduced in #2614, since I fixed this the first
time back in #1422.
----
_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>
## 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 WASI canary was breaking with the newest Rust version due to the new
WASI build targets:
https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html
## Description
<!--- Describe your changes in detail -->
Updating the version of `cargo-component` used to build our WASI canary.
Made the same update in the `aws-sdk-rust` repo:
https://github.com/awslabs/aws-sdk-rust/pull/1168
## 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 same change was made in the canary workflow in the `aws-sdk-rust`
repo and run successfully there:
* PR: https://github.com/awslabs/aws-sdk-rust/pull/1168
* Canary run:
https://github.com/awslabs/aws-sdk-rust/actions/runs/9575014647
## 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
Update lockfiles based on [the codegen
release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-06-18)
(a release including code changes in aws runtime crates, smithy runtime
crates, or codegen code).
## Testing
- [ ] Existing tests in CI
----
_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 endpoint partition parsing was dropping the `implicitGlobalRegion`
value
## Description
<!--- Describe your changes in detail -->
Updated our Partition structs to include that value and update the
parser to include it.
## 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 check for `implicitGlobalRegion` to existing partition unit tests
## 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._
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 -->
We have had numerous recent issues where updated dependencies have
broken our build/release process. This seeks to fix that in a brute
force way by manually generating Cargo.lock files for our main
workspaces.
## Description
<!--- Describe your changes in detail -->
Introduce a new gradle task `generateAllLockfiles` (and some child tasks
that it invokes) that generates lock files for
* `aws-config` crate
* `aws/rust-runtime` workspace
* `rust-runtime` workspace
* the superset workspace generated by the `assemble` task
* NOTE: This Cargo.lock is actually generated from the workspace in the
`aws-sdk-rust` repo, saved in this repo, and copied into place at build
time. Generating this one requires a local copy of the `aws-sdk-rust`
repo whose absolute path is indicated by the `-Paws-sdk-rust-path`
parameter.
## 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 ran our E2E tests against 3 commits to confirm that the Cargo.lock
files operate as we expect:
* `9d84980ee2e37deadb7e45450d65c5e6bc69e07c` The head commit from this
PR which has our Cargo.lock files
* ✅ Passes
* `d9d9fcec2de0e898bcc804ee0bb31393d7098e72` with lockfiles and with the
`httparse` and `crc323c` crates unpinned
* ✅ Passes
* `df75beb160890b2a9c382c8a2f7da8d7d0ddd3c8` with no lockfiles and has
the `httparse` and `crc32c` crates unpinned
* ❌ Fails (as expected)
This series of tests confirms that that Cargo.lock files will protect us
against bad dependency updates going forward.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
----
_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._
## Motivation and Context
There are extra service specific model tests in various
`aws/sdk/aws-models/[sdk-id]-tests.smithy` files. These are currently
manually duplicated to `aws-sdk-rust/aws-models`. This PR seeks to make
`smithy-rs` the single source of truth for these tests and remove the
need to copy them into `aws-sdk-rust` at all.
## Description
* move all `-tests.smithy` into a new sibling directory
`aws-models-extra` and _ALWAYS_ include these regardless of what the
path to `aws-models` is (e.g. even when overriding it and generating the
full SDK by setting `-Paws.sdk.models.path`
* move all `-tests.smithy` from `aws-sdk-rust/aws-models` into this
directory (previously only `s3`, `route53`, and `glacier` were in this
repo but there are also additional tests for `ebs`, `batch`, and `sqs`.
This makes `smithy-rs` the only source of truth for additional AWS SDK
model tests
* see https://github.com/awslabs/aws-sdk-rust/pull/1161
* update the `s3` model to latest and revert
ttps://github.com/smithy-lang/smithy-rs/pull/3641
## Testing
Local + CI
_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/smithy-lang/smithy-rs/issues/3672
## Description
Pin to a newer working version of `crc32c` (will still pin to a
particular version to avoid a breaking change, until the lockfile
protection is available)
## Testing
- Verified locally build of `aws-smithy-checksums` with the updated
`crc32c`
----
_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 -->
part of the `hyper` 1.0 upgrade
## Description
<!--- Describe your changes in detail -->
This PR adds information about the connector used to send a request to
the metadata included in the user agent.
## 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 added an integration test.
## 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._
This commit gets rid of some Clippy and Rust doc warnings we produce in
generated code, which are surfaced in our codegen integration tests. The
aim is that eventually we will be able to deny Clippy and Rust doc
warnings in #3678 (despite us baking in `RUSTDOCFLAGS="-D warnings"` and
`RUSTFLAGS="-D warnings"` in our CI Docker image, we curently clear
these in codegen integration tests). Note that denying compiler warnings
is separately tracked in #3194.
The commit contains fixes for the following:
- Unconditionally referring to the `crate::types` module in Rust docs
when
the Smithy model is such that it is not generated.
- Broken intra-crate doc links for client documentation.
- Incorrectly escaping Rust reserved keywords when referring to
operation names in Rust docs.
- An unnecessary semi-colon when rendering additional client
plugins.
- Not escaping brackets in text when rendering Rust docs containing
HTML, that are interpreted as broken links.
- A broken link to unit variants of unions.
- Using `TryFrom` instead of `From` when infallibly converting from
`&str` to `String` when deserializing an `@httpPayload` in the server.
- Using a redundant closure with `unwrap_or_else` when falling back to a
`@default` boolean or number value for a `document` shape, instead of
`unwrap_or`.
- Not opting into `clippy::enum_variant_names` when rendering the
`Operation` enum in the server (since we render the operation names
that were modeled as-is).
----
_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
To fix current CI and release pipeline failures coming from
`aws-smithy-runtime` and `aws-sigv4` now depending on `httparse` version
1.9.0 or greater.
## Testing
Tests in CI
----
_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 -->
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
Reverts e4260f5ab6
## Description
We recently had a CI failure where some of the SDK codegen integration
tests encountered a cargo dependency graph resolution error
([example](https://github.com/smithy-lang/smithy-rs/actions/runs/9351952926/job/25740638098?pr=3677#step:3:639)).
The way the issue manifested is as follows:
1. A preceding test `SdkCodegenIntegrationTest.smokeTestSdkCodegen`
generated a `Cargo.lock` at the top-level directory of a shared test
workspace whose `tokio` dependency did NOT include the `macros` feature:
```
[[package]]
name = "tokio"
version = "1.38.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ba4f4a02a7a80d6f274636f0aa95c7e383b912d41fe721a31f29e29698585a4a"
dependencies = [
"backtrace",
"bytes",
"libc",
"mio",
"pin-project-lite",
"socket2",
"windows-sys 0.48.0",
]
```
2. During its turn, `CredentialProviderConfigTest`, which is one of the
failed tests and depends on the `macros` feature of `tokio`, generated
its own test crate and made it as a member of the workspace, for
instance:
```
[workspace]
resolver = "2"
members = ["smithy-test1475522104838765591"]
```
3. Docker containers used by GitHub action have the `CARGO_HOME` set to
`/opt/cargo` where it stores crates io index, cached crates, and so on.
The registry cache did not contain the sought crate `tokio-macros-2.3.0`
at the end of previous step:
```
bash-5.2# ls /opt/cargo/registry/cache/index.crates.io-6f17d22bba15001f/tokio-
tokio-1.37.0.crate tokio-macros-2.2.0.crate tokio-rustls-0.24.1.crate tokio-util-0.7.11.crate
tokio-1.38.0.crate tokio-native-tls-0.3.1.crate tokio-util-0.7.10.crate
```
(`bash-5.2#` indicates that we shelled into a container)
4. Running `cargo test` from the workspace root (or from within the
crate generated at step 2) then triggered the error in question:
```
bash-5.2# cargo t --all-features
error: failed to select a version for the requirement `tokio-macros = "~2.3.0"`
candidate versions found which didn't match: 2.2.0, 2.1.0, 2.0.0, ...
location searched: crates.io index
required by package `tokio v1.38.0`
```
Whether the issue occurs or not for a given test depends upon the
contents of the lockfile of a workspace generated by prior tests. To
ensure we avoid this during codegen integration tests, this PR updates
crates io index before executing `cargo test`.
## Testing
- [x] Passed CI
- [x] Passed internal release pipeline E2E tests
----
_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
There are several service specific http request/response tests from
Smithy. These are similar to the protocol tests but apply only to a
specific service. We were tasked with ensuring some of the S3 URI
related tests were captured.
## Description
We currently were running the API gateway related tests as part of the
`aws/sdk-adhoc-test` package. There are also tests for
[machinelearning](https://github.com/smithy-lang/smithy/blob/main/smithy-aws-protocol-tests/model/awsJson1_1/services/machinelearning.smithy),
[glacier](https://github.com/smithy-lang/smithy/blob/main/smithy-aws-protocol-tests/model/restJson1/services/glacier.smithy),
and
[s3](https://github.com/smithy-lang/smithy/blob/main/smithy-aws-protocol-tests/model/restXml/services/s3.smithy).
I attempted to add all of these but hit issues.
1. `machinelearning` can be enabled but we have yet to actual implement
the [customization](https://github.com/smithy-lang/smithy-rs/issues/139)
that would allow this test to pass.
2. `s3` pulls in `aws-config` as a dev dependency for _reasons_ and this
causes conflicts between relocated and non-relocated runtime crates. The
`sdk-adhoc-test` package does not implement any of the runtime
relocation and Cargo.toml processing that the `sdk` build does (nor do I
want to pursue that).
For now I've enabled the `glacier` tests and copied the S3 specific
tests into `s3-tests.smithy` so that they are built and tested with the
actual S3 model. In the future we can either (1) fix the build issues
allowing us to remove these tests in favor of the ones defined in Smithy
or (2) ideally these tests get implemented in the real upstream service
models and we don't have to do anything special to get them.
## Testing
Tested locally and CI
----
_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 -->
https://github.com/smithy-lang/smithy-rs/issues/3676
## Description
Internals one of our tests was leveraging has changed in latest release
of `tracing-test`, updates version and test to be compatible.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Landon James