-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Customizable Operations #1647
Conversation
We didn't previously have an inlineables module for smithy stuff so I created one as part of this PR. In the process, I copied the current AWS inlineables implementation closely and I may have done things in a strange way. I look forward to y'alls comments and criticism. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
The test failures are due to the feature being defined in an inlineable. I'll have to move it into codegen unless we change how we handle the smithy client generics. I'm going to ask around internally to get a feel for what people think about that. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exciting!
...kotlin/software/amazon/smithy/rust/codegen/smithy/generators/client/FluentClientDecorator.kt
Outdated
Show resolved
Hide resolved
remove: unnecessary build.gradle.kts change add: missing copyright headers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some comments to delineate the new fluent client codegen from the old fluent client codegen
...kotlin/software/amazon/smithy/rust/codegen/smithy/generators/client/FluentClientGenerator.kt
Show resolved
Hide resolved
...kotlin/software/amazon/smithy/rust/codegen/smithy/generators/client/FluentClientGenerator.kt
Outdated
Show resolved
Hide resolved
...kotlin/software/amazon/smithy/rust/codegen/smithy/generators/client/FluentClientGenerator.kt
Show resolved
Hide resolved
...kotlin/software/amazon/smithy/rust/codegen/smithy/generators/client/FluentClientGenerator.kt
Show resolved
Hide resolved
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me! Just a question and some simple fixes.
aws/sdk-codegen/src/main/kotlin/software/amazon/smithy/rustsdk/RetryPolicyDecorator.kt
Outdated
Show resolved
Hide resolved
...n/src/main/kotlin/software/amazon/smithy/rust/codegen/smithy/generators/GenericsGenerator.kt
Outdated
Show resolved
Hide resolved
...n/src/main/kotlin/software/amazon/smithy/rust/codegen/smithy/generators/GenericsGenerator.kt
Outdated
Show resolved
Hide resolved
...kotlin/software/amazon/smithy/rust/codegen/smithy/generators/client/FluentClientGenerator.kt
Outdated
Show resolved
Hide resolved
A new generated diff is ready to view.
A new doc preview is ready to view. |
update: add IntelliJ idea folder to .gitignore update: use nullable type instead of optional in GenericsGenerator update: use clearer naming and types in GenericsGenerator add: fancy formatter for generic type parameters update: use new type param formatter for customizable op generics
A new generated diff is ready to view.
A new doc preview is ready to view. |
…uentClientGenerator directly
A new generated diff is ready to view.
A new doc preview is ready to view. |
@@ -45,3 +45,6 @@ gradle-app.setting | |||
|
|||
# Rust build artifacts | |||
target/ | |||
|
|||
# IDEs | |||
.idea/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing newline.
override fun toGenericsGenerator(): GenericsGenerator { | ||
return GenericsGenerator() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
override fun toGenericsGenerator(): GenericsGenerator { | |
return GenericsGenerator() | |
} | |
override fun toGenericsGenerator() = GenericsGenerator() |
private val typeArgs: MutableList<GenericTypeArg> | ||
|
||
init { | ||
typeArgs = genericTypeArgs.toMutableList() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not simply:
private val typeArgs: MutableList<GenericTypeArg> | |
init { | |
typeArgs = genericTypeArgs.toMutableList() | |
} | |
private val typeArgs = genericTypeArgs.toMutableList() |
However, do we need mutability here? I don't see the add
method being used.
...n/src/main/kotlin/software/amazon/smithy/rust/codegen/smithy/generators/GenericsGenerator.kt
Outdated
Show resolved
Hide resolved
...n/src/main/kotlin/software/amazon/smithy/rust/codegen/smithy/generators/GenericsGenerator.kt
Outdated
Show resolved
Hide resolved
val bound: RuntimeType? = null, | ||
) | ||
|
||
class GenericsGenerator(vararg genericTypeArgs: GenericTypeArg) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for creating this generator. We will reuse it for the server, we have a slew of generics and bounds in the operation registry.
nit: would be nice to have some docs on usage and unit tests.
...n/src/main/kotlin/software/amazon/smithy/rust/codegen/smithy/generators/GenericsGenerator.kt
Outdated
Show resolved
Hide resolved
codegen/src/main/kotlin/software/amazon/smithy/rust/codegen/rustlang/Writable.kt
Outdated
Show resolved
Hide resolved
codegen/src/main/kotlin/software/amazon/smithy/rust/codegen/rustlang/Writable.kt
Show resolved
Hide resolved
.../kotlin/software/amazon/smithy/rust/codegen/smithy/generators/client/FluentClientGenerics.kt
Outdated
Show resolved
Hide resolved
update: use Unit instead of "()" update: RustSymbolFormatter to handle RustTypes add: tests for rustTypeParameters
A new generated diff is ready to view.
A new doc preview is ready to view. |
add: tests for GenericsGenerator update: tests for rustTypeParameters add: docs for GenericsGenerator refactor: rustInline to be rustInlineTemplate. Now, it can template, and won't trim input update: code per PR comments
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
released as part of v0.49.0 |
## Motivation and Context Port [Customizable Operation](#1647) to orchestrator ## Description This PR implements `CustomizableOperation` in the orchestrator. Just like the counterpart in the middleware, it is created when the `customize` method (in the orchestrator mode) on a fluent builder is called. The `customize` method in the orchestrator could technically be made a synchronous method because there is no need to create an operation, which requires `async`, therefore making the `customize` method in the middleware `async`. However, during the transition from the middleware to the orchestrator, the integration tests ([example](https://github.com/awslabs/smithy-rs/blob/31c152d9af53afb9a5e6edf9df3def57931b9c1e/aws/sdk/integration-tests/s3/tests/signing-it.rs#L36)) need to be able to run in both modes. For this reason, the `customize` method in the orchestrator is temporarily marked as `async`. Regarding methods defined on the new `CustomizableOperation`, they include `mutate_request` and `map_request` from the counterpart in the middleware. However, it did not port `map_operation` because there is no operation to map on. Most use cases for `map_operation` is put things in a property bag. The new `CustomizableOperation` provides an `interceptor` method to accomplish the same, i.e putting things in a config bag. Finally, for integration tests to run in both modes, the code gen emits the implementation of the `customize` method differently depending on the active Smithy runtime mode, similar to what the implementation of `send` method does. ## Testing Added one `sra-test` for mutating a request. ---- _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: Yuki Saito <[email protected]> Co-authored-by: John DiSanti <[email protected]>
## Motivation and Context Port [Customizable Operation](#1647) to orchestrator ## Description This PR implements `CustomizableOperation` in the orchestrator. Just like the counterpart in the middleware, it is created when the `customize` method (in the orchestrator mode) on a fluent builder is called. The `customize` method in the orchestrator could technically be made a synchronous method because there is no need to create an operation, which requires `async`, therefore making the `customize` method in the middleware `async`. However, during the transition from the middleware to the orchestrator, the integration tests ([example](https://github.com/awslabs/smithy-rs/blob/31c152d9af53afb9a5e6edf9df3def57931b9c1e/aws/sdk/integration-tests/s3/tests/signing-it.rs#L36)) need to be able to run in both modes. For this reason, the `customize` method in the orchestrator is temporarily marked as `async`. Regarding methods defined on the new `CustomizableOperation`, they include `mutate_request` and `map_request` from the counterpart in the middleware. However, it did not port `map_operation` because there is no operation to map on. Most use cases for `map_operation` is put things in a property bag. The new `CustomizableOperation` provides an `interceptor` method to accomplish the same, i.e putting things in a config bag. Finally, for integration tests to run in both modes, the code gen emits the implementation of the `customize` method differently depending on the active Smithy runtime mode, similar to what the implementation of `send` method does. ## Testing Added one `sra-test` for mutating a request. ---- _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: Yuki Saito <[email protected]> Co-authored-by: John DiSanti <[email protected]>
## Motivation and Context Port [Customizable Operation](#1647) to orchestrator ## Description This PR implements `CustomizableOperation` in the orchestrator. Just like the counterpart in the middleware, it is created when the `customize` method (in the orchestrator mode) on a fluent builder is called. The `customize` method in the orchestrator could technically be made a synchronous method because there is no need to create an operation, which requires `async`, therefore making the `customize` method in the middleware `async`. However, during the transition from the middleware to the orchestrator, the integration tests ([example](https://github.com/awslabs/smithy-rs/blob/31c152d9af53afb9a5e6edf9df3def57931b9c1e/aws/sdk/integration-tests/s3/tests/signing-it.rs#L36)) need to be able to run in both modes. For this reason, the `customize` method in the orchestrator is temporarily marked as `async`. Regarding methods defined on the new `CustomizableOperation`, they include `mutate_request` and `map_request` from the counterpart in the middleware. However, it did not port `map_operation` because there is no operation to map on. Most use cases for `map_operation` is put things in a property bag. The new `CustomizableOperation` provides an `interceptor` method to accomplish the same, i.e putting things in a config bag. Finally, for integration tests to run in both modes, the code gen emits the implementation of the `customize` method differently depending on the active Smithy runtime mode, similar to what the implementation of `send` method does. ## Testing Added one `sra-test` for mutating a request. ---- _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: Yuki Saito <[email protected]> Co-authored-by: John DiSanti <[email protected]>
## Motivation and Context Port [Customizable Operation](#1647) to orchestrator ## Description This PR implements `CustomizableOperation` in the orchestrator. Just like the counterpart in the middleware, it is created when the `customize` method (in the orchestrator mode) on a fluent builder is called. The `customize` method in the orchestrator could technically be made a synchronous method because there is no need to create an operation, which requires `async`, therefore making the `customize` method in the middleware `async`. However, during the transition from the middleware to the orchestrator, the integration tests ([example](https://github.com/awslabs/smithy-rs/blob/31c152d9af53afb9a5e6edf9df3def57931b9c1e/aws/sdk/integration-tests/s3/tests/signing-it.rs#L36)) need to be able to run in both modes. For this reason, the `customize` method in the orchestrator is temporarily marked as `async`. Regarding methods defined on the new `CustomizableOperation`, they include `mutate_request` and `map_request` from the counterpart in the middleware. However, it did not port `map_operation` because there is no operation to map on. Most use cases for `map_operation` is put things in a property bag. The new `CustomizableOperation` provides an `interceptor` method to accomplish the same, i.e putting things in a config bag. Finally, for integration tests to run in both modes, the code gen emits the implementation of the `customize` method differently depending on the active Smithy runtime mode, similar to what the implementation of `send` method does. ## Testing Added one `sra-test` for mutating a request. ---- _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: Yuki Saito <[email protected]> Co-authored-by: John DiSanti <[email protected]>
## Motivation and Context Port [Customizable Operation](smithy-lang/smithy-rs#1647) to orchestrator ## Description This PR implements `CustomizableOperation` in the orchestrator. Just like the counterpart in the middleware, it is created when the `customize` method (in the orchestrator mode) on a fluent builder is called. The `customize` method in the orchestrator could technically be made a synchronous method because there is no need to create an operation, which requires `async`, therefore making the `customize` method in the middleware `async`. However, during the transition from the middleware to the orchestrator, the integration tests ([example](https://github.com/awslabs/smithy-rs/blob/31c152d9af53afb9a5e6edf9df3def57931b9c1e/aws/sdk/integration-tests/s3/tests/signing-it.rs#L36)) need to be able to run in both modes. For this reason, the `customize` method in the orchestrator is temporarily marked as `async`. Regarding methods defined on the new `CustomizableOperation`, they include `mutate_request` and `map_request` from the counterpart in the middleware. However, it did not port `map_operation` because there is no operation to map on. Most use cases for `map_operation` is put things in a property bag. The new `CustomizableOperation` provides an `interceptor` method to accomplish the same, i.e putting things in a config bag. Finally, for integration tests to run in both modes, the code gen emits the implementation of the `customize` method differently depending on the active Smithy runtime mode, similar to what the implementation of `send` method does. ## Testing Added one `sra-test` for mutating a request. ---- _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: Yuki Saito <[email protected]> Co-authored-by: John DiSanti <[email protected]>
Motivation and Context
#1112, aws-sdk-rust#537
Description
SDK customers occasionally need to add additional HTTP headers to requests, and currently,
the SDK has previously had no easy way to accomplish this. This PR adds a feature that provides an easier way to augment requests that is compatible with the fluent client.
Before:
After:
Major credit to @jdisanti who wrote the original RFC for this feature.
Testing
I wrote an integration test
Checklist
CHANGELOG.next.toml
if I made changes to the smithy-rs codegen or runtime cratesCHANGELOG.next.toml
if I made changes to the AWS SDK, generated SDK code, or SDK runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.