-
Notifications
You must be signed in to change notification settings - Fork 576
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
Regression to Blob types with respect to SDKv2 #5181
Comments
Also, I'm not quite sure why Kinesis:
Lambda:
|
The smithy blob type is In the past, users requested to get string type for output, like s3.getObject, and we had provided mixin in #3977 which allows consumers to transform Unit8Array to relevant types. We can add a similar fix for accepting string in input and do the conversion internally. |
The automatic conversion of blob types was implemented in #4836, which was published in https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.357.0 This is applicable to TypeScript types of blob. The SDK is not doing any conversion from string to Uint8Array. Verified using the following code: // invokeLambdaFn.ts
import { Lambda } from "@aws-sdk/client-lambda";
const client = new Lambda({ region: "us-west-2" });
client.invoke({
FunctionName: "test-function-name",
Payload: JSON.stringify({ foo: "bar" }),
}); $ npx tsc --version
Version 5.1.6 v3.356.0TypeScript TS2322 error is thrown $ npx tsc invokeLambdaFn.ts
invokeLambdaFn.ts:7:3 - error TS2322: Type 'string' is not assignable to type 'Uint8Array'.
7 Payload: JSON.stringify({ foo: "bar" }),
~~~~~~~
node_modules/@aws-sdk/client-lambda/dist-types/models/models_0.d.ts:3373:5
3373 Payload?: Uint8Array;
~~~~~~~
The expected type comes from property 'Payload' which is declared here on type 'InvokeCommandInput'
Found 1 error in invokeLambdaFn.ts:7 v3.357.0No error is thrown by TypeScript $ npx tsc invokeLambdaFn.ts Is there a specific API call in CDK which we can use for testing? One which fails on sending a string for a blob type. |
AwsApi and AwsCustomResource, for example. But there's not really anything to test for you right now. Thanks for the effort, let's hope this makes it to Lambda NodeJS 18.x runtime soon! |
there may be a workaround involving providing a custom implementation to |
we updated the default base64 encoder to accept strings and not just byteArrays. Is this still an issue in the latest SDK version? |
This issue has not received a response in 1 week. If you still think there is a problem, please leave a comment to avoid the issue from automatically closing. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread. |
Describe the feature
It seems that input fields marked as "Blob" types used to permissively accept types in SDKv2, but no longer do so in SDKv3.
As an example, Kinesis
PutRecord
:SDKv2
https://github.com/aws/aws-sdk-js/blob/ecd7c9c2ad37560326e1645b83ad981dbee7f4f9/clients/kinesis.d.ts#L343
SDKv3
aws-sdk-js-v3/clients/client-kinesis/src/models/models_0.ts
Line 2201 in 4adc48a
Use Case
Why does this matter?
We are the CDK, migrating from SDKv2 to SDKv3. There are multiple places where we are driving the SDK not with our own, type-checked values, but using values we get from users and pass on to the SDK.
string
s where BLOBs were expected, which works perfectly well with SDKv2, but is now all of a sudden broken for SDKv3.string
s, but are now broken. What's worse, the JSON events are going to contain the strings that they contain, and there's both no way to representUint8Array
s in JSON, as well as no ability for the user to control the format of the event in the first place.If we knew that a
Uint8Array
was expected, it would be trivial for us to do a run-time conversion, but unfortunately we have no insight into the type that is expected at run time (remember, this is long past the TypeScript type checking stage). Therefore, we can't do the conversion, and have no other solution than to pass on the wrongly typed value and have the call fail.Proposed Solution
Can the SDK not follow Postel's Law here, and also accept the other types you used to accept in SDKv2, doing an under-the-covers conversion as necessary?
Alternatively, provide us with a run-time inspectable table telling us the types of all fields, so that we can do that conversion as necessary?
Other Information
No response
Acknowledgements
SDK version used
latest
Environment details (OS name and version, etc.)
Nodejs 20
The text was updated successfully, but these errors were encountered: