## Motivation and Context
Customers want to be able to use `serde` with Smithy models. For
details, see the
[RFC](https://github.com/smithy-lang/smithy-rs/blob/configurable-serde/design/src/rfcs/rfc0045_configurable_serde.md)
## Description
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Implementation of `serde::Serialize` for smithy-rs code generators. This
takes the approach of a trait, `SerializeConfigured` which _returns_ a
type that implements `Serialize`. This allows customers to control serde
behavior for their use case.
```rust
/// Trait that allows configuring serialization
/// **This trait should not be implemented directly!** Instead, `impl Serialize for ConfigurableSerdeRef<T>`**
pub trait SerializeConfigured {
/// Return a `Serialize` implementation for this object that owns the object. This is what you want
/// If you need to pass something that `impl`s serialize elsewhere.
fn serialize_owned(self, settings: SerializationSettings) -> impl Serialize;
/// Return a `Serialize` implementation for this object that borrows from the given object
fn serialize_ref<'a>(&'a self, settings: &'a SerializationSettings) -> impl Serialize + 'a;
}
```
This can be used as follows:
```rust
serde_json::to_string(&my_struct.serialize_ref(&SerializationSettings::redact_sensitive_fields());
```
Currently, this codegen plugin is not used by anything. It can be
enabled by bringing it in scope during code generation & adding the
`@serde` trait to the model for the fields where serialization is
desired. This will allow the SDK (if they choose to) roll it out only
for specific types or services that have customer demand.
There are a number of follow on items required:
- [x] Ensure the generated impls work for `Server` codegen
- [ ] Generate `Deserialize` implementations
- [x] Test the implementation all Smithy protocol test models (ensure it
compiles)
## Testing
Unit test testing serialization with a kitchen-sink model
## 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._
---------
Co-authored-by: david-perez <d@vidp.dev>
## Motivation and Context
Implements [RFC: File-per-change
changelog](https://smithy-lang.github.io/smithy-rs/design/rfcs/rfc0042_file_per_change_changelog.html#rfc-file-per-change-changelog)
## Description
When this PR is merged to `main`, it will impact developer workflow for
creating a changelog entry that goes with a PR.
Prior to this, one edited `CHANGELOG.next.toml` to enter a changelog
entry, but it often caused merge conflicts among us. With this PR, one
creates a `.md` file (any filename stem will do) under the
`smithy-rs/.changelog` directory. This Markdown file has the YAML front
matter, and it can be created manually or via the `ChangeLogger` CLI
(see [this
commit](83cda76608)
for more details).
Here are the highlights of the code changes:
- [The release
script](https://github.com/smithy-lang/smithy-rs/pull/3774/files#diff-162dc2b82eb3d72b105291d2fc5fc8d10c4fbc1e6f35862bc08ac0d6a7c53f76)
has been pointed to `smithy-rs/.changelog`. This is pretty much what it
takes to let the `smithy-rs` release infra switch to the new changelog
mode.
-
[sdk-lints](efcc772b37)
now disallows `CHANGELOG.next.toml`. It will complain if the file is
present.
- The `--source-to-truncate` option for the `changelogger`'s `render` is
now optional because our internal release infra code no longer needs to
specify that option (i.e. there is nothing to truncate there).
- Tests in `smithy-rs-tool-common` and `changelogger` have been updated
so TOML changelog entries used in tests have been re-written to Markdown
changelog entries. We want to avoid giving the false impression that
TOML changelog entries are still well-supported.
## Testing
- Existing tests & lints in CI
- Ran `smithy-rs` [dry-run
release](https://github.com/smithy-lang/smithy-rs/actions/runs/10100442953)
and confirmed the correctness of `CHANGELOG.md` and
`SDK_CHANGELOG.next.json` in the release artifacts
- Ran the internal release and confirmed `CHANGELOG.md` was rendered
correctly in `aws-sdk-rust`
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
I was speaking to several customers that found our connection poisoning
terminology confusing. To address this, I've changed the messaging and
I've also created a new section in the docs that explains some errors in
greater detail. To direct users to these explanations, I've added a link
to the `tracing::info!` call.
I propose that we consider doing the same any time we identify error
messaging that
- must be kept succinct to avoid logging too much info
- must be more understandable to our users.
----
_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
- 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>
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>
## 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._
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>
Fix broken links as a result of repo movement
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The previous names are just too verbose. This PR shortens them and tries
to make things clearer.
----
_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
See [rendered
RFC](df518bfb59/design/src/rfcs/rfc0039_behavior_major_versions.md)
## Description
This add `BehaviorMajorVersions` to the SDK and wires them in up and
down the stack.
## Testing
- [x] lots of ITs / UTs
## 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
This RFC describes a way to allow services to add model previously
unmodeled variants in the future without breaking customers.
## Description
[Rendered](https://github.com/awslabs/smithy-rs/blob/errors-forward-compat-rfc/design/src/rfcs/rfc0039_forward_compatible_errors.md)
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
This PR fixes issues introduced by moving the repository from
awslabs/smithy-rs to smithy-lang/smithy-rs.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This is a pared-down version of #2809.
This is the code-generated version of the
david-perez/smithy-rs-service-config#2 POC.
This introduces a code-generated `PokemonServiceConfig` object which is
provided to the service builder constructor via
`PokemonService::builder(config: PokemonServiceConfig)`. This will
displace the
current `builder_without_plugins` and `builder_with_plugins`,
deprecating them.
We will eventually remove them.
The motivation is to have a single place where to register plugins and
layers.
Smithy traits can leverage this object to inject methods that can apply
plugins
and layers. For example, an `@authorization` trait implementer could
vend a
smithy-rs decorator that pre-applied an authorization plugin inside the
`${serviceName}Config` object, possibly exposing a method to pass in any
runtime arguments needed to configure the middleware.
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
- [ ] Upgrade guidance
- [x] changelog
To allow seamless adoption of the incoming `http` crate, we're updating
our client crates to use an intermediate type.
## Description
Update _client_ code to use `HttpRequest`. Some internal code still uses
`http::Request` but those usages are limited.
## Testing
CI
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This PR makes the orchestrator traits more idiomatic by making them
verbs.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
add SUMMARY link to new RFC
----
_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
Implementation of the HTTP request wrapper type from RFC
## Description
RFC + implementation of HttpRequest
## Testing
- IT/UT
- Separate PR which uses this type in implementation of the SDK
----
_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
When the returned field is a list, there is _almost_ never a reason to
know if the returned value was null or `[]` — this addresses the 99%
case.
Before:
```rust
fn blah(&self) -> Option<&[T]> { self.blah.as_deref() }
```
After:
```rust
fn blah(&self) -> &[T] { self.blah.as_deref().unwrap_or_default() }
```
**note**: no impact on servers by default, see codegen diff.
## Description
Update accessors for lists.
## Testing
- [x] codegen diff audit (no server changes)
- [x] unit tests
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## 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._
---------
Co-authored-by: ysaito1001 <awsaito@amazon.com>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
Co-authored-by: kstich <kevin@kstich.com>
## Motivation and Context
Add a quick note about the CRT
CI fails because of rust compilation I'll see if I can fix easily
otherwise will mark as ignored
----
_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 TLS connector page is missing
## Description
Render the TLS connector documentation page
## 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._
---------
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
Co-authored-by: david-perez <d@vidp.dev>
## Motivation and Context
[Rendered](d3eaf5eea5/design/src/rfcs/rfc0036_http_dep_elimination.md)
## Description
An RFC describing the need and proposed path for limiting the scope of
our HTTP dependency.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
This PR makes some progress towards documenting the
`aws-smithy-runtime-api` crate, as well as some additional work to make
it more stable:
- Places the `client` module behind a `client` feature so that it will
be possible to add a `server` module/feature in the future.
- Deletes `ConfigBagAccessors`.
- Renames auth types to reflect changes in the internal spec.
- Moves `RequestAttempts` into the `client::retries` module.
- Moves several types that were in floating around in
`client::orchestrator` to their own modules.
- Renames `Connector` to `HttpConnector`.
- Changes `DynResponseDeserializer` to `SharedResponseDeserializer` for
consistency with serialization, and also so that it could be moved into
runtime components or config in the future (since those need to
implement `Clone`).
- Updates the identity and auth design doc.
- Updates READMEs and crate-level documentation.
- Fixes most, but not all, the missing documentation in the crate.
- Hides the builder macros.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
So far, servers have tacitly worked with the notion that plugins come in
two flavors: "HTTP plugins" and "model plugins":
- A HTTP plugin acts on the HTTP request before it is deserialized, and
acts on the HTTP response after it is serialized.
- A model plugin acts on the modeled operation input after it is
deserialized, and acts on the modeled operation output or the modeled
operation error before it is serialized.
However, this notion was never reified in the type system. Thus, users
who pass in a model plugin where a HTTP plugin is expected or
viceversa in several APIs:
```rust
let pipeline = PluginPipeline::new().push(http_plugin).push(model_plugin);
let app = SimpleService::builder_with_plugins(http_plugins, IdentityPlugin)
.post_operation(handler)
/* ... */
.build()
.unwrap();
```
would get the typical Tower service compilation errors, which can get
very confusing:
```
error[E0631]: type mismatch in function arguments
--> simple/rust-server-codegen/src/main.rs:47:6
|
15 | fn new_svc<S, Ext>(inner: S) -> model_plugin::PostOperationService<S, Ext> {
| -------------------------------------------------------------------------- found signature defined here
...
47 | .post_operation(post_operation)
| ^^^^^^^^^^^^^^ expected due to this
|
= note: expected function signature `fn(Upgrade<RestJson1, (PostOperationInput, _), PostOperationService<aws_smithy_http_server::operation::IntoService<simple::operation_shape::PostOperation, _>, _>>) -> _`
found function signature `fn(aws_smithy_http_server::operation::IntoService<simple::operation_shape::PostOperation, _>) -> _`
= note: required for `LayerFn<fn(aws_smithy_http_server::operation::IntoService<..., ...>) -> ... {new_svc::<..., ...>}>` to implement `Layer<Upgrade<RestJson1, (PostOperationInput, _), PostOperationService<aws_smithy_http_server::operation::IntoService<simple::operation_shape::PostOperation, _>, _>>>`
= note: the full type name has been written to '/local/home/davidpz/workplace/smithy-ws/src/SmithyRsSource/target/debug/deps/simple-6577f9f79749ceb9.long-type-4938700695428041031.txt'
```
This commit introduces the `HttpPlugin` and `ModelPlugin` marker traits,
allowing plugins to be marked as an HTTP plugin, a model plugin, or
both. It also removes the primary way of concatenating plugins,
`PluginPipeline`, in favor of `HttpPlugins` and `ModelPlugins`, which
eagerly check that whenever a plugin is `push`ed, it is of the expected
type. The generated service type in the server SDKs'
`builder_with_plugins` constructor now takes an `HttpPlugin` as its
first parameter, and a `ModelPlugin` as its second parameter.
I think this change perhaps goes counter to the generally accepted
wisdom that trait bounds in Rust should be enforced "at the latest
possible moment", that is, only when the behavior encoded in the trait
implementation is relied upon in the code (citation needed).
However, the result is that exposing the concepts of HTTP plugin and
model plugin in the type system makes for code that is easier to reason
about, and produces more helpful compiler error messages.
Documentation about the plugin system has been expanded, particularly on
how to implement model plugins.
## 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
Closes https://github.com/awslabs/smithy-rs/issues/1839
Currently, `Plugin` is parameterized by protocol and operation. To
improve symmetry, extensibility and uniformity we switch this to be
parameterized by service instead. The protocol can still be recovered
via the `type Protocol` associated type on `ServiceShape`.
## Description
- Add `ServiceShape` trait, encoding the properties of a Smithy service.
- Change `Plugin<Protocol, Operation, S>` to `Plugin<Service, Operation,
S>`.
- Add `FilterByOperation` and `filter_by_operation` `Plugin`s.
This replaces the existing custom interceptor disable logic with shared
logic to allow generally disabling any public interceptors from Runtime
plugins. The previous behavior was very brittle because it relied
heavily on runtime plugin execution order.
## Motivation and Context
- simplify presigning behavior
- generalize logic to disable interceptors
## Description
Create `disable_interceptor` struct, which, when inserted into the
configuration bag can disable an interceptor via the `Interceptors`
execution interface.
## Testing
- ` (cd aws/sdk/build/aws-sdk/sdk/s3 && cargo test --test presigning)`
## 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
Closes https://github.com/awslabs/smithy-rs/issues/2004
## Description
Run `mdbook test` over the `design` folder.
## TODO
- [x] Ignore the RFC sections using `ignore` tag on the code blocks.
- [ ] Fix the remaining examples.
- [x] Ensure local `rust-runtime` dependencies are being used.
---------
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
Co-authored-by: 82marbag <69267416+82marbag@users.noreply.github.com>
* Show how to plug a connector
* For TLS: keep rustls, only
## 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._
---------
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
## Motivation and Context
This PR adds a design doc for client identity and auth for the new
client orchestrator.
----
_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 document is intended to capture the philosophy and ideas
underpinning the current state of the orchestrator and should grow
alongside the orchestrator.
Abhinav requested something like this and I think it'll be helpful for
future people.
----
_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>
* Remove deprecated ResolveAwsEndpoint and related interfaces.
* update changelog with pointer
* Rename AwsEndpointDecorator to have a more appropriate name
* Allow endpoint resolver to be omitted
Russell Cohen