## Motivation and Context
Recent changes (e.g.
242814cbcf)
were backported to release branch but a new smithy-rs release hasn't
been made.
`runtime-versioner audit` is pulling latest release of
`release-2024-04-30` which is causing it to see a diff to `aws-runtime`
(which was released today with the SDK release).
```
> runtime-versioner audit
2024-05-07T22:33:45.710839Z INFO runtime_versioner::command::audit: 'aws-config' changed and was version bumped from 1.3.0 to 1.4.0
2024-05-07T22:33:46.403927Z INFO runtime_versioner::command::audit: 'aws-smithy-runtime' changed and was version bumped from 1.4.0 to 1.5.0
2024-05-07T22:33:46.436213Z INFO runtime_versioner::command::audit: 'aws-smithy-runtime-api' changed and was version bumped from 1.5.0 to 1.6.0
2024-05-07T22:33:46.468490Z INFO runtime_versioner::command::audit: 'aws-smithy-types' changed and was version bumped from 1.1.8 to 1.1.9
2024-05-07T22:33:46.588902Z INFO runtime_versioner::command::audit: 'aws-types' changed and was version bumped from 1.2.0 to 1.2.1
aws-runtime 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 PR bumps the version to get around this which is causing preview
build failures and will cause release issues until fixed.
----
_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
Updates the expected result for a `CreateMultipartUpload` protocol test
based on an S3's upcoming model update
----
_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 the last [failed backport workflow
run](https://github.com/smithy-lang/smithy-rs/actions/runs/8971718857/job/24638066793)
## Description
The error `refusing to merge unrelated histories` was caused by the same
reason described in prior PRs (#3479, #3480). We need to tell git
unshallow histories so that it knows they are actually related.
## Testing
Ran the failed workflow from this branch and successfully generated a
backport PR3625.
----
_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
Mark unused code as such for [the latest
compiler](https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html).
## Description
We use the latest compiler as part of our release of AWS SDKs, which
ensures that 3rd party dependencies should build even if they release a
new version requiring a newer MSRV than we specify within this
repository. At the time of writing, the latest compiler is 1.78.0, and
it is now able to detect more unused code patterns that our current MSRV
1.75.0.
The compiler 1.78.0 unfortunately caused a build failure in
[check-sdk-codegen-unit-tests](e8449bd152/tools/ci-scripts/check-sdk-codegen-unit-tests)
as follows
```
src/smithy-rs/aws/rust-runtime/aws-runtime/src/env_config/section.rs:21:8
|
16 | pub(crate) trait Section {
| ------- methods in this trait
...
21 | fn properties(&self) -> &HashMap<String, Property>;
| ^^^^^^^^^^
...
27 | fn is_empty(&self) -> bool;
| ^^^^^^^^
|
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(dead_code)]
```
We cannot eliminate this failure even if we specify `RUSTFLAGS="-D
warnings"` because the generated client tests will render the following
in its dot cargo directory:
```
cat .cargo/config.toml
[build]
rustflags = ["--deny","warnings"]
```
Plus, trying to eliminate `--deny warnings` contradicts what
https://github.com/smithy-lang/smithy-rs/issues/3194 is trying to
achieve. To fix it, we will follow what the compiler suggests to fix.
## Testing
Verified it fixed our internal 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._
## 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>
## Motivation and Context
Pins major and minor versions for `fastrand` during testing in
`aws-smithy-runtime`
## Description
`aws-smithy-runtime` uses the `fastrand` crate in a waiters' [unit
test](eac52eb69c/rust-runtime/aws-smithy-runtime/src/client/waiters/backoff.rs (L137)).
Two days ago, `fastrand` of version 2.1.0 got released (previously
2.0.2). According to [this
PR](https://github.com/smol-rs/fastrand/issues/20), a minor version bump
can cause seed-value-breaking changes.
This PR will only allow patch-level bumps for `fastrand` in
`[dev-dependencies]`.
## Testing
Relies on testing in CI (since CI in the main branch currently fails, if
CI passes in this PR we're good).
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
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._
## Motivation and Context
This PR adds support for custom partition to be loaded at runtime. Use
cases for this feature are mostly private, i.e. using a pre-GA region
from the AWS SDK for Rust (or more broadly, from Smithy SDK for Rust).
## Description
Today, AWS SDK for Rust uses
[sdk-partitions.json](c6f4f53506/aws-models/sdk-partitions.json).
Unless a customer specifies a full URL using the `.endpoint_url` method,
the SDK is responsible for constructing the full URL for an endpoint
given a specified region, using a partitions file. It is essentially a
recipe for how to do so, such as providing DNS suffix like
`csp.hci.ic.gov`.
Certain customers need to use the SDK for a pre-GA region that is not
listed in the said public partitions file. When a region is not listed,
it will not be mapped to a known partition, and the SDK defaults to
construct endpoints using the patterns for the public AWS partition,
i.e. `amazonaws.com`. The assumption of "defaulting to the public
partition" may not always work for those customers. This PR, therefore,
adds an environment variable so that customers can specify a full path
to a custom partitions file.
Why look up the environment variable at runtime but not at codegen time?
The primary reason is maximum availability for the feature. Customers
can use a custom partitions file even for SDKs already published on
crates.io. If configuration were at codegen time, it wouldn't be
possible to use a custom partitions file for those SDKs.
## Testing
Since the code change uses an environment variable, no automated tests
have added for this. Instead, manually verified the following. Given a
fake custom paritions file that includes
```
{
"id" : "custom-partition",
"outputs" : {
"dnsSuffix" : "custom.com",
"dualStackDnsSuffix" : "custom.com",
"implicitGlobalRegion" : "us-custom-region-1",
"name" : "custom-partition",
"supportsDualStack" : false,
"supportsFIPS" : true
},
"regionRegex" : "^us\\-custom\\-*",
"regions" : {
"us-custom-region-1" : {
"description" : "US CUSTOM REGION 1"
}
}
}
```
when we run the following test
```
#[tokio::test]
async fn test_custom_partition() {
let (http_client, captured_request) = capture_request(None);
std::env::set_var("SMITHY_CLIENT_SDK_CUSTOM_PARTITIONS", <full path to that custom partition>);
let sdk_config = aws_config::from_env().region("us-custom-region-1").http_client(http_client).load().await;
let client = Client::new(&sdk_config);
let _ = client.list_buckets().send().await;
dbg!(captured_request.expect_request());
}
```
`dbg!` shows a fully constructed endpoint URL:
```
uri: Uri {
as_string: "https://s3.us-custom-region-1.custom.com/?x-id=ListBuckets",
parsed: H0(
https://s3.us-custom-region-1.custom.com/?x-id=ListBuckets,
),
},
```
If we do not set the environment variable in the above snippet, then we
get this endpoint URL instead:
```
uri: Uri {
as_string: "https://s3.us-custom-region-1.amazonaws.com/?x-id=ListBuckets",
parsed: H0(
https://s3.us-custom-region-1.amazonaws.com/?x-id=ListBuckets,
),
},
```
----
_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 READMEs to internal tools
- Delete completely outdated documentation from the design folder
----
_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>
The verify TLS CI step is flaky at the moment, so it would be helpful to
be able to run it manually against main to see if it was the PR that
broke it, or if it is its general flakiness.
----
_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
The CI job that checks CI credentials fails when run on forks, resulting
in daily job failure alerts in forks.
Example failure:
https://github.com/iamjpotts/aws-smithy-rs/actions/runs/8768654532
See https://github.com/smithy-lang/smithy-rs/issues/3519.
## Description
For the `Daily Credentials Verification` workflow, add a condition on
each of its jobs so that they will only run for the
`smithy-lang/smithy-rs` repo and not any forks.
## Testing
No code changes.
## 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
----
CI only; no change log entry required.
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Signed-off-by: Joshua Potts <8704475+iamjpotts@users.noreply.github.com>
It seems upgrading cargo-semver-checks to 0.30 made it take
significantly longer than before (going from less than 20 minutes up to
between 1-4 hours). Reverting it back to 0.24.1 for now to keep CI
faster.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
While implementing waiters in another branch, I discovered and fixed a
number of issues with the path matcher codegen logic. These issues were:
- Generated code for nested flatten projections failed to compile due to
the first projection producing a `Vec<Vec<&T>>` instead of `Vec<&T>`.
- Path matchers that don't use input were taking input as an argument
anyway, which results in an unnecessary clone of the input when used by
the generated waiter logic.
- The comparisons generated by `RustWaiterMatcherGenerator` would fail
to compile whenever comparing a string against an enum.
This PR fixes all these issues.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Description
See
[README](b172a1ea4c/aws/sdk/benchmarks/s3-express/README.md)
## Testing
Here are performance numbers measured on `Amazon Linux 2 x86_64 5.10`
with `c5.4xlarge` in `us-west-2`, and benchmarks ran with
`NUMBER_OF_ITERATIONS=1` to allow for quick execution
```
For 64KB objects:
PUT: [11.750 ms 12.025 ms 12.291 ms] / [67.737 ms 76.367 ms 85.531 ms]
GET: [16.071 ms 16.270 ms 16.461 ms] / [19.941 ms 22.622 ms 26.167 ms]
PUT + DELETE: [21.492 ms 22.132 ms 22.755 ms] / [75.608 ms 86.056 ms 98.329 ms]
For 1MB objects:
PUT [37.400 ms 39.130 ms 40.769 ms] / [144.30 ms 160.93 ms 180.93 ms]
GET [14.968 ms 15.193 ms 15.408 ms] / [24.872 ms 28.417 ms 32.984 ms]
PUT + DELETE: [52.106 ms 54.875 ms 57.503 ms] / [172.38 ms 185.00 ms 200.28 ms]
```
In each row, a tuple on the left of `/` is for execution time for an S3
Express bucket and that on the right is for a regular S3 bucket. Each
tuple is a 99% confidence interval, containing `[<the lower end> <the
mean> <the higher end>]`.
----
_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: AWS SDK Rust Bot <aws-sdk-rust-primary@amazon.com>
Co-authored-by: AWS SDK Rust Bot <97246200+aws-sdk-rust-ci@users.noreply.github.com>
Co-authored-by: Zelda Hessler <zhessler@amazon.com>
Co-authored-by: Russell Cohen <rcoh@amazon.com>
## 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
Upgrade JDK to 17 in the repository
----
_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
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._
The original wording still mentions "alpha", so this PR brings it up to
GA times.
----
_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
Adds a new step description for external contributors regarding running
canary and PR bot workflows.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
It looks like I will need to render specialized fluent builders for
waiters. This PR is some prerequisite work to split fluent builder
generation out of the fluent client generator into its own thing. This
makes it possible to refactor the fluent builder generator to be more
configurable in a follow up PR so that it can generate waiter fluent
builders as well.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Zelda Hessler <zhessler@amazon.com>
This PR adds reasonable timeouts to each CI job so that a PR isn't held
up for six hours by a hung runner.
----
_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 updates all the dependency lock files, upgrades the S3
throughput benchmark to SDK 1.x, and updates the build image
dependencies.
----
_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 latest documentation is Smithy v2. In most cases it's identical. As
far as I can tell, there are no links to items with breaking changes
between v1 and v2.
---------
Co-authored-by: Harry Barber <hlbarber@amazon.co.uk>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
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._
Related to #3429
----
_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>
In the time gap between smithy-rs and SDK releases, the
runtime-versioner can incorrectly allow changes to aws/rust-runtime
crates without version bumping. This PR fixes this issue by detecting
this edge case.
----
_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 step `trim-changelog-next-on-main` has been
[skipped](https://github.com/smithy-lang/smithy-rs/actions/workflows/release.yml?query=actor%3Aaws-sdk-rust-ci)
probably since a release branch `smithy-rs-release-1.x.y` was created.
## Description
We no longer directly remove released entries from CHANGELOG.next.toml
on `main`. We do so by backport PRs to merge `smithy-rs-release-1.x.y`
to `main`. So `open-backport-pull-request` now depends on `release`,
instead of `trim-changelog-next-on-main`.
## Testing
`open-backport-pull-request` depending on `release` can only be "tested"
in prod runs, so we'll see what happens in the next release. If
`open-backport-pull-request` fails, we will manually run it and address
whatever issue that comes up.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The new canary secrets weren't being propagated from the root prod
release workflow into the CI workflow, so the canary was failing. This
PR propagates those secrets, and also makes it possible to run the full
CI workflow in a dry-run release so that it's possible to test in the
future.
----
_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 Smithy waiter matcher union codegen.
----
_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>
This PR removes the now unused upgrade-runtime-crates-version subcommand
from publisher, and also switches it to regex-lite since it doesn't need
the full regex feature set.
----
_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 -->
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._
The service env config work I did was flawed in that it didn't respect
the precedence of programmatic config. This PR
adds a way of tracking the precedence up to the point of converting the
SdkConfig into a service config. Now, env config will only be resolved
when config was not set programmatically. I added tests to `aws-config`
for the origin tracking to ensure it works.
_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
Original issue: https://github.com/smithy-lang/smithy-rs/issues/3427
See the motivation section of the RFC.
## Description
Proposes a new RFC that changes the default behavior of `SdkConfig` and
`SharedCredentialsProvider`/`SharedTokenProvider` w.r.t caching and
cache partitions.
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Aaron Todd