## 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._
## Description
This does several things:
1. Upgrade to RusTLS 0.23 which enables FIPS support
2. Add smoke test of the clients. This revealed a bug where https URLs
were not supported.
This is technically a breaking change because I added `non_exhaustive`
to the CryptoMode enum.
<!--- Describe your changes in detail -->
## Testing
New integration tests. I expect this to fail in CI since I'll need to
update the build image to match.
## 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._
Related PR: https://github.com/smithy-lang/smithy-rs/pull/1892/
## Motivation and Context
This change allows users to define inline IAM policies and/or set
predefined policies (using their ARNs) with
`WebIdentityTokenCredentialsProvider`
## Description
Adds `policy` and `policy_arns` to `WebIdentityTokenCredentialsProvider`
builder.
## Testing
## 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
Improve docs around retry classifiers.
----
_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/2863https://github.com/awslabs/aws-sdk-rust/issues/1060
## Description
<!--- Describe your changes in detail -->
This PR adds a new feature: the ability to source service-specific
config from the environment.
This is **only** supported when creating a service config from an
`SdkConfig`. I've posted [a
guide](https://github.com/smithy-lang/smithy-rs/discussions/3537) to our
discussions board.
[This also adds support for setting an endpoint URL in environment
config.](https://github.com/smithy-lang/smithy-rs/issues/2863)
## 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 have written several tests ensuring config is extracted with the
correct precedence.
## 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>
Co-authored-by: ysaito1001 <awsaito@amazon.com>
Merging #3485 uncovered a semver hazard in the S3 stalled stream
protection test due to a subtle (but intentional) change in grace period
behavior for stalled streams. That semver hazard was going to cause the
SDK release to fail, so #3485 was reverted, and this PR modifies the
test so that it will pass with both versions of stalled stream
protection as a temporary measure. Once this PR is merged and released,
then the new stalled stream protection can be merged again.
I tested this by updating the runtime-versioner in #3540 so that I could
patch the currently released SDK with these test changes in place, with
a local copy of smithy-rs that has the new stalled stream protection
implementation. I ran all the tests across all the services in this
configuration to verify this was the only hazard that will be hit.
----
_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 removes the (unneeded) flags from the smithy-rs release job that
set the stable/unstable versions.
## Testing
- [x] ran a dry run on the branch
## 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
We've hit issues several times where semver hazards were not discovered
until release. Now that we've removed version arguments, we can now run
this test on PRs.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The stalled stream protection changes are triggering a semver hazard
that will break the release. Need to revert it temporarily to fix this
issue.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
tracked in issue #3518
----
_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 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.
----
_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 is the first of two PRs to remove the concept of stable/unstable
versions from the release process. This PR will cause a full docker
rebuild, so I'm splitting it out to merge first to make iterating on the
second PR easier.
----
_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 same reason for #3500, which is GitHub actions do not allow us to
manually trigger them unless they are first checked-in to the main
branch.
## Description
This PR adds a skeletal workflow file for manually invoking canary
within `smithy-lang/smithy-rs` on behalf of external contributors.
Forked repositories will be missing repository secrets to run the canary
in CI so it will always fail for external contributors. As a workaround,
maintainers will manually trigger `manual-canary.yml`, given a PR number
from an external contributor as input.
A subsequent PR will fill in the blank.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Fixes aws-sdk-rust#1111
This is *technically* a breaking change but since this was released
recently and it's documented that this API shouldn't be used, this can
probably be considered a bug, which is better fixed now than later.
---------
Co-authored-by: ysaito1001 <awsaito@amazon.com>
## Motivation and Context
A prerequisite for running canary in smithy-rs CI
## Description
This PR is essentially refactoring so that `canary-stack.ts` library can
be used by both `smithy-rs` and `aws-sdk-rust`. CDK apps are then split
into `bin/smithy-rs` and `bin/aws-sdk-rust`; the former is used by our
local development and the latter is used by our internal release
pipeline.
Merging this PR to the main branch will not affect anything. However, we
will need to update our internal release pipeline to use
`bin/aws-sdk-rust/*` instead when we release new SDKs:
- `npm run build` -> `npx tsc && npx cdk --app "node
build/bin/aws-sdk-rust/canary.js" synth`
- `npx cdk bootstrap` -> `npx cdk bootstrap --app "ts-node
--prefer-ts-exts bin/aws-sdk-rust/canary.ts"`
- `npx cdk --app "node build/bin/canary-only.js" synth` -> `npx cdk
--app "node build/bin/aws-sdk-rust/canary-only.js" synth`
- `npx cdk --app "node build/bin/canary-only.js" deploy --outputs-file
cdk-outputs.json` -> `npx cdk --app "node
build/bin/aws-sdk-rust/canary-only.js" deploy --outputs-file
cdk-outputs.json`
Also, when this PR is merged, we're ready to deploy a new canary stack
`smithy-rs-canary-stack` used by smithy-rs CI.
## Testing
> we will need to update our internal release pipeline to use
`bin/aws-sdk-rust/*` instead
Verified internally that it passed the release pipeline.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Precommit hooks and CI have started failing due to `runtime-versioner`
reporting `aws-config` requires a version bump.
While the most recent change to that crate was made by [this
PR](https://github.com/smithy-lang/smithy-rs/pull/3491) only updating
test-related code, it does still require a version bump.
----
_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 -->
There is a rarely-triggered bug
(https://github.com/awslabs/aws-sdk-rust/issues/1079) that can occur
when the runtime is dropped between requests. Although this is
definitely the _wrong thing to do_(tm) which should still aim to at
least protect the users from bad data in this case.
This adds an interceptor which validates that the body returned is the
correct length.
## Description
- Adds an interceptor that computes the actual content length of the
body and compares it to the actual length
## Testing
- Integration style test. Note that this is very hard to test using
Hyper because Hyper will attempt to mitigate this issue.
## 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: AWS SDK Rust Bot <aws-sdk-rust-primary@amazon.com>
## Motivation and Context
## Description
After [upgrading to
actions/upload-artifact@v4](https://github.com/smithy-lang/smithy-rs/pull/3497),
it seems to have brought a behavior change where an artifact with the
same name is [disallowed by
default](https://github.com/smithy-lang/smithy-rs/actions/runs/8423689643/job/23067178393#step:4:639)
within a workflow run.
This happened during a
[release](https://github.com/smithy-lang/smithy-rs/blob/main/.github/workflows/release.yml)
workflow where it first invoked ci.yml (which then called
`generate-smithy-rs-release` and created an artifact with that action
name) and then called `generate-smithy-rs-release` by itself (attempted
to create an artifact with that action name again, leading to the error
above). This was not a problem previously when we were using
`actions/upload-artifact@v3`.
This PR explicitly sets `overwrite: true` to bring back the old behavior
for a place that's affected.
----
_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 was caused by a runtime crate referencing another runtime
crate with a version dependency instead of a path dependency. I've added
an error message that tells us how to fix this if it comes up again:
```txt
crate `aws-smithy-mocks-experimental` depends on crate `aws-smithy-types` crate by version instead of by path. Please update it to use path dependencies for all 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
Add a skeletal workflow file for later invoking canary in `aws-sdk-rust`
from within `smithy-rs` CI. GitHub actions do not allow us to manually
trigger them unless they are first checked-in to the main branch.
(**Disclaimer**: we may end up executing `canary-runner` from a
smithy-rs CI step without invoking canary in `aws-sdk-rust`, but for the
sake of illustration, assume we invoke canary in `aws-sdk-rust` for the
rest of the PR description)
## Description
To briefly explain where we're going, a diagram below illustrates how
relevant workflow files look like when we run canary in `smithy-rs` CI
(in the context of this PR, it will check-in a file that says
`canary.yml` in red).
<p align="center">
<img width="600" alt="Screen Shot 2023-02-08 at 3 47 05 PM"
src="https://github.com/smithy-lang/smithy-rs/assets/15333866/4a336f7b-8d41-42e4-b59d-4aa87ab91093">
</p>
We will add a new CI step that runs canary in `aws-sdk-rust` from within
`smithy-rs`. It will work when run as part of `cr-pr.yml` but it won't
when run from `cr-pr-forks.yml` (i.e. for external contributors) because
their forked repos do not have a necessary repository secret to invoke
canary in `aws-sdk-rust`. To work around, we will manually run
`smithy-lang/smithy-rs/.github/workflows/canary.yml` on their behalf
with the name of a fork and a commit hash.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
RuleMode describes how rules will be interpreted.
- In RuleMode::MatchAny, the first matching rule will be applied, and
the rules will remain unchanged.
- In RuleMode::Sequential, the first matching rule will be applied, and
that rule will be removed from the list of rules.
Also adds a `make_client!` macro produces a Client configured with a
number of Rules and appropriate test default configuration.
## Motivation and Context
Working through improvements on experimental mocks after implementing
them in the Cloudwatch Logs example.
## Testing
Unit tests, doctests,
## Checklist
- [x] 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
Fixes an S3-related bug introduced when s3 Express was added
## Description
This PR fixes a bug where s3 Express auth flow was incorrectly used when
no auth schemes were available for an endpoint. This use case was
observed in test settings and manifested itself as a confusing behavior.
To address this issue, the fix ensures that an auth scheme for S3
express will be registered after that for sigv4 has been registered.
## Testing
Added an integration test
`s3_express_auth_flow_should_not_be_reached_with_no_auth_schemes`
## 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._
## Motivation and Context
Now that canary [passed for the last three
days](https://github.com/awslabs/aws-sdk-rust/actions/runs/8335320052),
we can turn s3 express canary on by default.
## Testing
Verified internally that our release pipeline passes canary with s3
express canary enabled.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Our workflows used outdated actions and that was causing deprecation
warnings for Node v16. Those annoyed me so I updated everything.
----
_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
Resolves [issue
2523](https://github.com/smithy-lang/smithy-rs/issues/2523) to migrate
to Smithy IDL v2
## Description
I followed the [Smithy Migration
Guide](https://smithy.io/2.0/guides/model-translations/migrating-idl-1-to-2.html)
to convert the models. One change was that by moving the inputs/outputs
into the operation, it did result in a renaming of the CapturePokemon
structures. They went from CapturePokemonEvents(Input|Output) to
CapturePokemon(Input|Output). From a brief look at the commit history,
it seems the API used to be named different and the inputs/outputs
weren't renamed at that time. So I decided to have them match the normal
naming convention (it didn't seem to break any tests).
## Testing
As this was my first commit, I ran almost every target I could discover,
but I think the key ones were:
* codegen-server-test
* codegen-client-test
* examples: `make 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._
## Motivation and Context
- https://github.com/awslabs/aws-sdk-rust/issues/1095
## Description
Update the JSON parser generator to allow for `null` to be set in
unions. Servers can send unions like this:
```json
{
"AmazonElasticsearchParameters": null,
"AmazonOpenSearchParameters": null,
"AppFlowParameters": null,
"AthenaParameters": null,
"AuroraParameters": null,
"AuroraPostgreSqlParameters": null,
"AwsIotAnalyticsParameters": null,
"BigQueryParameters": null,
"DatabricksParameters": null,
"Db2Parameters": null,
"DenodoParameters": null,
"DocumentDBParameters": null,
"DremioParameters": null,
"ExasolParameters": null,
"GoogleAnalyticsParameters": null,
"JiraParameters": null,
"MariaDbParameters": null,
"MongoAtlasParameters": null,
"MongoDBParameters": null,
"MySqlParameters": null,
"OracleParameters": null,
"PostgreSqlParameters": null,
"PrestoParameters": null,
"RdsParameters": null,
"RedshiftParameters": null,
"S3Parameters": {
"IsUploaded": false,
"ManifestFileLocation": {
"Bucket": "deided-bucket.prod.us-east-1",
"Key": "sales/manifest.json"
},
"RoleArn": null
},
"SalesforceParameters": null,
"SapHanaParameters": null,
"ServiceNowParameters": null,
"SnowflakeParameters": null,
"SparkParameters": null,
"SqlServerParameters": null,
"StarburstParameters": null,
"TeradataParameters": null,
"TrinoParameters": null,
"TwitterParameters": null
}
```
This caused our parser to fail.
## 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. -->
- [x] New unit test
- [x] Dry run against new [smithy protocol
test](https://github.com/smithy-lang/smithy/pull/2180)
## 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 -->
Part of the endpoint config work I'm doing
## Description
<!--- Describe your changes in detail -->
This change does two things:
- add support for setting an endpoint URL from the env or profile file
- add support for ignoring endpoint URLs sourced from the env and
profile file
## 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 many 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 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
Fix CI breakage during release.
----
_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
A follow-up task that resolves one of the `TODO(Post S3Express release)`
## Description
This PR ensures that `BehaviorVersion` is threaded through from an outer
S3 client to the inner S3 client when `DefaultS3ExpressIdentityProvider`
is constructed.
I considered the alternative where `BehaviorVersion` would be stored in
`ConfigBag`using another flavor like `StoreOnce` and obtained from the
bag within
`DefaultS3ExpressIdentityProvider::express_session_credentials`. But
ensuring `StoreOnce` per `ConfigBag` was not enough for
`BehaviorVersion` since there could be nested `ConfigBag`s where each
`ConfigBag` was separate. `BehaviorVersion` needs to be unique across
those different `ConfigBag`s and the fact that we store
`BehaviorVersion` outside `RuntimeComponents` or `ConfigBag` is a
reasonable choice from that perspective (the ease of guaranteeing the
uniqueness of `BehaviorVersion`).
## Testing
Relied on existing tests in 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 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 `0.12.0` version of `wasi` suffered from a bug the could impact
users using lower versions of `wit-bindgen` dependencies. Mixed versions
of `wit-bindgen` generated bindings in a single project would cause a
symbol collision. This is fixed by newer versions of `wit-bindgen` and
`wasi = 0.12.1` contains bindings generated by one of these newer
versions. See this issue for details:
https://github.com/bytecodealliance/wit-bindgen/issues/849 and a longer
discussion of the issue on Zulip
[here](https://bytecodealliance.zulipchat.com/#narrow/stream/327223-wit-bindgen/topic/Component.20failing.20to.20compile.20with.20mixed.20wit-bindgen.20versions/near/422068264).
## Description
<!--- Describe your changes in detail -->
Bumped version of `wasi` dependency in `aws-amithy-wasm` from `0.12.0`
-> `0.12.1`
## 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
----
_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 <john@vinylsquid.com>
This PR creates a new time/sleep primitive for testing the minimum
throughput stall protection async logic. All the previous code in the
`test_util` module was split out into sub-modules, and the new code is
in the `test_util::tick_advance_sleep` module.
----
_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
Switch to the sparse index broke the publishers check if whether or not
a version was already published.
## Description
Fix check, add tests.
## Testing
- Ran test against the real sparse index.
----
_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 -->
## Description
<!--- Describe your changes in detail -->
## 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 -->
- [ ] 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
I'm not sure what changed but I was able to reproduce the failure from
https://github.com/smithy-lang/smithy-rs/actions/runs/8242141624/job/22564640708
with the downloaded release artifact. Because the clone was shallow, git
did not attempt to push because the histories were unrelated.
Of course, they are in reality, but because the history is shallow git
doesn't know that.
I verified this allowed a dry run push to succeed locally.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The SDK runtime patcher tool used during smithy-rs release to detect
semver breaks was breaking due to the new aws-smithy-wasm crate since it
had a bad assumption in the logic to determine if a runtime crate
changed. This PR corrects that logic to state the runtime crate doesn't
need patching if it didn't exist previously.
----
_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
- Avoid getting a warning on every build
- Cargo will only allow one `0.12.0` to be published so this metadata
doesn't impact anything. A comment was added to clarify.
----
_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
Fixes the issue of `canary-wasm` not being able to locate generated
crates in our release pipeline
## Description
The `canary-wasm` crate has
[Cargo.toml](https://github.com/smithy-lang/smithy-rs/blob/main/tools/ci-cdk/canary-wasm/Cargo.toml)
checked-in, whose SDK dependencies assume path locations with respect to
build artifacts within the `smithy-rs` repository. However, those
locations can be different in our release pipeline (the same reason why
there's no manifest file checked-in for
[canary-lambda](https://github.com/smithy-lang/smithy-rs/tree/main/tools/ci-cdk/canary-lambda)
and it needs to be generated on the fly by `canary-runner`'s
`build-bundle` subcommand).
To fix this, `canary-runner` now generates the manifest for
`canary-wasm`.
## Testing
- [x] Added unit tests for `canary-runner`
- [x] Verified in our release pipeline that canary built and passed
----
_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
- #1925
## Description
This adds a minimal Hyper client, focusing on not exposing any unstable
APIs. For this reason, the `Client::Builder` customization API is not
exposed anymore. We do this because at some point in the future, we will
likely move away from the hyper-util based Client.
The code for this was lifted directly from the Hyper 0.14 implementation
but updated for new traits.
However, this does come with some new valuable pieces:
1. Support for aws-lc (no FIPS yet)
2. Support for providing a custom DNS resolver
## Testing
- E2E test with Hyper. A Canary should also be added
(https://github.com/awslabs/aws-sdk-rust/issues/1089)
## 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._
AWS SDK Rust Bot