feat: support orchestrator #1435
Conversation
milesziemer
force-pushed
the
interceptors-impl
branch
2 times, most recently
from
e86e753 to
c019f22
Compare
milesziemer
force-pushed
the
interceptors-impl
branch
4 times, most recently
from
3d35527 to
9b05b97
Compare
Sources/Core/AWSSDKForSwift/Documentation.docc/AWSSDKForSwift.md
Outdated
Show resolved
Hide resolved
| override fun renderMiddlewareInit( | ||
| ctx: ProtocolGenerator.GenerationContext, | ||
| writer: SwiftWriter, | ||
| op: OperationShape | ||
| ) { |
There was a problem hiding this comment.
Does FlexibleChecksumsResponseIntegration need a branch for useInterceptors? (e.g. for S3)
There was a problem hiding this comment.
See #1435 (comment)
| override fun renderMiddlewareInit( | ||
| ctx: ProtocolGenerator.GenerationContext, | ||
| writer: SwiftWriter, | ||
| op: OperationShape | ||
| ) { |
There was a problem hiding this comment.
Does FlexibleChecksumsRequestIntegration need a branch for useInterceptors? (e.g. for S3)
There was a problem hiding this comment.
It's a little roundabout how this works, but to render a MiddlewareRenderable, render gets called, which by default handles useInterceptors itself, and calls renderMiddlewareInit. Most middleware initialization works exactly the same whether using interceptors or not, so I added some abstraction to MiddlewareRenderable in the smithy-swift PR: https://github.com/smithy-lang/smithy-swift/pull/694/files#diff-60728c54157d6f8ad167a46845e0c2c47bc5abb02644411b20f5e5102a113942R48-R70
There was a problem hiding this comment.
@milesziemer so does that mean FlexibleChecksumsRequestIntegration doesn't need a branch for useInterceptors because render will be called anyway which already goes down that branch? Additionally, should this be refactored into an interceptor instead of a middleware?
There was a problem hiding this comment.
so does that mean FlexibleChecksumsRequestIntegration doesn't need a branch for useInterceptors because render will be called anyway which already goes down that branch?
Yes
Additionally, should this be refactored into an interceptor instead of a middleware?
If you mean the swift implementation, it is, just in smithy-lang/smithy-swift#694
| override fun renderMiddlewareInit( | ||
| ctx: ProtocolGenerator.GenerationContext, | ||
| writer: SwiftWriter, | ||
| op: OperationShape | ||
| ) { |
There was a problem hiding this comment.
Does S3ErrorWith200StatusIntegration need a branch for useInterceptors? (e.g. for S3)
There was a problem hiding this comment.
See #1435 (comment)
milesziemer
force-pushed
the
interceptors-impl
branch
2 times, most recently
from
8759528 to
55026cb
Compare
milesziemer
force-pushed
the
interceptors-impl
branch
from
55026cb to
72d9745
Compare
Updates the codegenerator and client libraries to enable using Orchestrator instead of OperationStack for operations. It is currently enabled for all protocol tests, and some services with integration tests. We can enable it for more services in the future. The codegen updates to support Orchestrator do change the code for services not using Orchestrator, but its just refactoring (EndpointResolverMiddleware for example).
milesziemer
force-pushed
the
interceptors-impl
branch
from
72d9745 to
7410996
Compare
Updates the codegenerator and client libraries to enable using Orchestrator instead of OperationStack for operations. It is currently enabled for all protocol tests, and some services with integration tests. We can enable it for more services in the future.
The codegen updates to support Orchestrator do change the code for services not using Orchestrator, but its just refactoring (EndpointResolverMiddleware for example).
See Orchestrator impl in smithy-lang/smithy-swift#694
For testing, I ran protocol tests and integration tests with interceptors enabled and disabled.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.