-
Notifications
You must be signed in to change notification settings - Fork 187
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
Allow for configuring interceptors on SDK client #2669
Conversation
This commit adds newtypes `SharedInterceptor` and `AddOnlyInterceptors` around existing types so that they can be used outside of their defining crates without revealing the implementation details.
This commit allows users to pass their own interceptors to `ConfigLoader` and to `SdkConfig`. The docs for their methods are marked as `#[doc(hidden)]` until the orchestrator is fully functional.
This commit updates the codegen to register user-passed-in interceptors. Registration takes place at the client config level and the operation config level. The former is handled in `ServiceRuntimePlugin` and the latter in service config `Builder`.
This commit updates `sra_test` to verify interceptors can be configured at the client config level. It also adds a test to ensure interceptors registered run according to the pre-defined priority.
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. |
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.
Nice work on this! I have mostly minor comments.
...re/amazon/smithy/rust/codegen/client/smithy/customizations/InterceptorConfigCustomization.kt
Outdated
Show resolved
Hide resolved
...re/amazon/smithy/rust/codegen/client/smithy/customizations/InterceptorConfigCustomization.kt
Outdated
Show resolved
Hide resolved
...re/amazon/smithy/rust/codegen/client/smithy/customizations/InterceptorConfigCustomization.kt
Outdated
Show resolved
Hide resolved
...oftware/amazon/smithy/rust/codegen/client/smithy/generators/config/ServiceConfigGenerator.kt
Outdated
Show resolved
Hide resolved
@@ -26,6 +26,7 @@ aws-smithy-client = { path = "../../sdk/build/aws-sdk/sdk/aws-smithy-client", de | |||
aws-smithy-http = { path = "../../sdk/build/aws-sdk/sdk/aws-smithy-http" } | |||
aws-smithy-http-tower = { path = "../../sdk/build/aws-sdk/sdk/aws-smithy-http-tower" } | |||
aws-smithy-json = { path = "../../sdk/build/aws-sdk/sdk/aws-smithy-json" } | |||
aws-smithy-runtime-api = { path = "../../sdk/build/aws-sdk/sdk/aws-smithy-runtime-api" } |
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.
I thought we said we weren't going to add this dep
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.
Hmm, if aws-config
does not depend on aws-smithy-runtime-api
, how does it know the type of Interceptor
that's part of the method signature for .interceptor
?
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.
Turns out that having a dependency from aws-config
(or aws-types
) onto aws-smithy-runtime-api
makes its hands tied to aws-smithy-runtime-api
when it comes to breaking changes. In other words, it becomes more difficult to introduce breaking changes in aws-smithy-runtime-api
because they are translated to breaking changes in aws-config
(we can only do so during a release that's allowed to introduce breaking changes but that makes development of aws-smithy-runtime-api
less nimble).
@@ -17,6 +17,7 @@ aws-smithy-async = { path = "../../../rust-runtime/aws-smithy-async" } | |||
aws-smithy-types = { path = "../../../rust-runtime/aws-smithy-types" } | |||
aws-smithy-client = { path = "../../../rust-runtime/aws-smithy-client" } | |||
aws-smithy-http = { path = "../../../rust-runtime/aws-smithy-http" } | |||
aws-smithy-runtime-api = { path = "../../../rust-runtime/aws-smithy-runtime-api" } |
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.
same here
Co-authored-by: John DiSanti <jdisanti@amazon.com>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
…egen/client/smithy/customizations/InterceptorConfigCustomization.kt Co-authored-by: John DiSanti <jdisanti@amazon.com>
…egen/client/smithy/customizations/InterceptorConfigCustomization.kt Co-authored-by: John DiSanti <jdisanti@amazon.com>
…egen/client/smithy/generators/config/ServiceConfigGenerator.kt Co-authored-by: John DiSanti <jdisanti@amazon.com>
…ps://github.com/awslabs/smithy-rs into ysaito/configure-interceptors-at-various-levels
This commit addresses #2669 (comment)
This commit addresses #2669 (comment)
A new generated diff is ready to view.
A new doc preview is ready to view. |
This commit addresses the following discussions: #2669 (comment) #2669 (comment)
A new generated diff is ready to view.
A new doc preview is ready to view. |
This commit addresses the following discussions: #2669 (comment) #2669 (comment)
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. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
This commit addresses #2669 (comment)
We will park this PR as a draft due to this reason. We'll revisit and update this once we're getting close to integrate the orchestrator with the rest of the world.
Description
This PR allows users to pass-in interceptors to
ConfigLoader
, toSdkConfig
. Client-level configured interceptors are eventually added toclient_interceptors
and operation-level interceptors tooperation_interceptors
, both of which are fields in theaws-smithy-runtime-api::client::interceptors::Interceptors
.SDK registers default set of (client-level & operation-level) interceptors, and the passed-in interceptors by a user will run after those default interceptors.
Admittedly, the code changes in the PR do not offer the ability to debug effectively when things go wrong with misconfigured interceptors (such as putting a wrong header value, leading to an unexpected request created). Adding traces could be an option. Open to suggestions/ideas.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.