-
Notifications
You must be signed in to change notification settings - Fork 4k
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
fix(events-targets): AwsApi is still using Node 16 #27002
Conversation
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
cf6e3e0
to
5a2aa36
Compare
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.
Approved with DNM because this seems like something others may want to give a peek as well.
try { | ||
const response = await client.send(new Command(commandInput)); | ||
delete response.$metadata; | ||
console.log('Response: %j', response); |
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 get that this handler is for triggering effects and doesn't return a value, but I still feel like there might be a sharp edge here wrt Uint8Array types. Someone could use this to trigger Kinesis today passing a string payload and that would break right? We just pass parameters as aws-events passes them I suppose, and I'm not even sure how we could place a marker or something for special case deserialization.
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.
Let me double check this,. But I'm quite sure the default logging algorithm does work for every object without fail. Unlike JSON.stringify() which often throws for unknown data.
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.
Checked this. It writes the payload as bytes into the log: {"0":123,"1":34,"2":101,"3":114,"4":114,"5":111,"6":114,"7":84,"8":121, ...
but doesn't fail. It's not great, but I think it's okay. If we have a generic transformation helper for API responses, we can add this later.
As for input: The function is called from EvenBridge (and the API directly) which is JSON by definition. Any other invocations would be outside the expected usage pattern and transformation into a string would be the users responsibility.
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 think Mitch' concern is the opposite?
If the SDKv2 API used to accept a string
and pass it on, but SDKv3 API now accepts a Uint8Array
for that same field (but not a string
), existing use cases are now broken.
There's also nothing we can do about it, and it's not really possible to pass that Uint8Array
properly from EventBridge, ever.
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.
Ah I see. Yes you are right about this.
It would seem like the only way to do this properly is to know exactly what fields are marked as "blob"s in the API
Yes and that seems unreasonable for us to do.
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.
That seems unreasonable, yes. But right now this is breaking certain use cases.
3504641
to
4e0e725
Compare
e1a7658
to
da2a7df
Compare
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
da2a7df
to
c29a105
Compare
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
…ay (#27034) In #27002 we have migrated the AwsApi Construct to SDKv3. However some SDKv3 Commands expect a `Uint8Array` in places where SDKv2 previously would accept a `string`. This is a problem because handler input is passed directly into the SDK calls and the input can only contain JSON data types. To solves this, we keep a list of SDK actions and parameters that should be coerced to `Uint8Array`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Migrate the `aws-api-handler` code to use SDKv3 and move it into `custom-resource-handlers`. Updates the Construct config to use the new code and Node18. To verify functionality, the existing integration test has been extended to include a new rule and target that can be asserted on. Includes a config change to the `custom-resource-handlers` package to run test from TS. Closes #26998 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ay (#27034) In #27002 we have migrated the AwsApi Construct to SDKv3. However some SDKv3 Commands expect a `Uint8Array` in places where SDKv2 previously would accept a `string`. This is a problem because handler input is passed directly into the SDK calls and the input can only contain JSON data types. To solves this, we keep a list of SDK actions and parameters that should be coerced to `Uint8Array`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Migrate the
aws-api-handler
code to use SDKv3 and move it intocustom-resource-handlers
.Updates the Construct config to use the new code and Node18.
To verify functionality, the existing integration test has been extended to include a new rule and target that can be asserted on.
Includes a config change to the
custom-resource-handlers
package to run test from TS.Closes #26998
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license