-
Notifications
You must be signed in to change notification settings - Fork 49
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
feat: support default checksums #1475
base: main
Are you sure you want to change the base?
Conversation
… jmespath-flatten
… flexible-checksums
This comment has been minimized.
This comment has been minimized.
A new generated diff is ready to view. |
This comment has been minimized.
This comment has been minimized.
/** | ||
* For any operations that require a checksum, set CRC32 if the user has not already configured a checksum. | ||
*/ | ||
private val useCrc32Checksum = object : ProtocolMiddleware { |
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.
question/correctness: S3 Express' spec says CRC32 is required. If we change our SDK's default algorithm to CRC64NVME in the future, how will we ensure CRC32 is still used for S3 Express? That's what this integration was responsible for.
Does S3 Express support CRC64NVME?
internal fun HeadersBuilder.removeCompositeChecksums(logger: Logger): Unit = | ||
names().forEach { header -> | ||
if (header.startsWith(CHECKSUM_HEADER_PREFIX, ignoreCase = true) && get(header)!!.isCompositeChecksum()) { | ||
logger.warn { "S3 returned a composite checksum, composite checksums are not supported, removing checksum" } |
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.
info: Log the composite checksum header name
* Removes composite checksums returned by S3 so that flexible checksums won't validate them. | ||
* Composite checksums are used for multipart uploads and end with "-#" where "#" is a number. |
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.
correctness/breaking change: I don't think we should be removing these headers, what if users need them for other purposes?
Isn't it easier to just ignore composite checksums in the flexible checksums implementation?
/** | ||
* Disable checksums entirely for s3:UploadPart requests. | ||
* Disables checksums for s3:UploadPart requests that use S3 express. |
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.
nit: S3 Express
@{protocol-name} | ||
@restJson1 | ||
@sigv4(name: "event-stream-test") | ||
@service(sdkId: "EventStreamTest") | ||
service TestService { version: "123", operations: [TestStreamOp] } | ||
|
||
{op-traits} |
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 added the templates back
I still don't see them
buildSrc/build.gradle.kts
Outdated
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.
Does this need to exist? buildSrc is treated as an included build which means every subproject will have these config options applied.
It seems odd to need this just for codegen tests
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.
It's the best way I could find to share a data class between subprojects, do you know of alternatives that would work better? I might've missed them
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.
You can make a new project that both of those subprojects depend on
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 is still a work in progress, I don't want to block the review because of this. I think worst case scenario we can come back and refactor this without it being a breaking change
@@ -265,6 +277,45 @@ class PresignerGenerator : KotlinIntegration { | |||
) | |||
} | |||
|
|||
checksumAlgorithmMember(op, ctx)?.let { checksumAlgorithmMember -> | |||
withBlock("input.#L?.value?.let { checksumAlgorithmString ->", "}", checksumAlgorithmMember) { |
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.
nit/naming/style: avoid Hungarian notation, checksumAlgorithmName
"#T.#T<Presigner> { #S }", | ||
coroutineContext, | ||
warn, | ||
"The requested checksum algorithm is not supported for pre-signed URL checksums, sending request without checksum.", |
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.
We should include which checksum algorithm the user chose and which are supported
@@ -287,4 +338,24 @@ class PresignerGenerator : KotlinIntegration { | |||
* > "my-object/example/photo.user". This is an incorrect path for that object. | |||
*/ | |||
private fun normalizeUriPath(service: ServiceShape) = service.sdkId != "S3" | |||
|
|||
/** | |||
* Gets the checksum algorithm member if a user can configure request checksums otherwise null |
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.
if a user can configure request checksums
style/docs: This seems awkward to me
"Gets the checksum algorithm member if configured on a request, otherwise null"
resolved + flexibleChecksumsRequestMiddleware | ||
resolved + flexibleChecksumsRequestMiddleware + configBusinessMetrics | ||
|
||
private val configBusinessMetrics = object : ProtocolMiddleware { |
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.
nit: middleware name and value's name should match
… flexible-checksums
A new generated diff is ready to view. |
A new generated diff is ready to view. |
import aws.smithy.kotlin.runtime.http.interceptors.FlexibleChecksumsResponseInterceptor | ||
|
||
/** | ||
* S3 variant of the flexible checksum interceptor where composite checksums are not validated |
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.
nit/docs: ... of the [FlexibleChecksumsResponseInterceptor]...
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.
correctness: This file should go in services/s3/common/src/aws/sdk/kotlin/services/s3/internal
with all the other S3-specific interceptors
/** | ||
* Determines if an operation is set up to send flexible request checksums | ||
*/ | ||
private fun requestChecksumsConfigured(ctx: ProtocolGenerator.GenerationContext, op: OperationShape): Boolean { |
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.
naming: "configured" implies that this is dependent on user behavior, but it's just based on the model. I suggest making this an extension function OperationShape.hasRequestAlgorithmMember(...)
val interceptor = if (ctx.model.expectShape<ServiceShape>(ctx.settings.service).isS3) { | ||
AwsRuntimeTypes.Http.Interceptors.S3FlexibleChecksumResponseInterceptor | ||
} else { | ||
RuntimeTypes.HttpClient.Interceptors.FlexibleChecksumsResponseInterceptor | ||
} |
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.
docs: let's add a comment here about why S3 needs a custom 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.
Now that I look at this again, we could replace S3FlexibleChecksumResponseInterceptor
with something more generic that could be applied to other services. In case other services start sending composite checksums in the future. What does the team think?
private fun usingS3Express(executionContext: ExecutionContext): Boolean = | ||
executionContext.getOrNull(AttributeKey(S3_EXPRESS_ENDPOINT_PROPERTY_KEY)) != S3_EXPRESS_ENDPOINT_PROPERTY_VALUE |
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.
style: Could be an extension function off ExecutionContext
internal class S3ExpressDefaultChecksumAlgorithm( | ||
private val isS3UploadPart: Boolean, | ||
) : HttpInterceptor { |
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.
style: This works but I think the previous implementation using two different interceptors was cleaner. It's not clear to me why this had to deviate so much from what we already had
- name: Save Test Reports | ||
if: failure() | ||
uses: actions/upload-artifact@v3 | ||
with: | ||
name: test-reports | ||
path: '**/build/reports' |
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.
What are these test reports used for?
A new generated diff is ready to view. |
Quality Gate passedIssues Measures |
A new generated diff is ready to view. |
Affected ArtifactsChanged in size
|
Issue #
Description of changes
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.