I have a regular Lambda stack that looks something like:
const lambdaDeleteDDBFn = new Function(this, 'LambdaToDeleteDDB', {
runtime: Runtime.NODEJS_10_X,
handler: 'delete-ddb-table-lambda.handle',
// The path should be relative to the root directory.
code: Code.asset('./lib/lambda'),
timeout: Duration.seconds(300),
environment: {
REGION: this.region,
TABLE_NAME: tableName
}
});
The ./lib/lambda directory looks normal as well which includes already compiled JS files:
$ ll lib/lambda/
total 64
-rw-r--r-- 1 user 1896053708 5324 3 Jan 09:17 create-invalid-stack-lambda.js
-rw-r--r-- 1 user 1896053708 4719 3 Jan 09:17 custom-resource-utils.js
-rw-r--r-- 1 user 1896053708 3501 3 Jan 09:17 delete-ddb-table-lambda.js
-rw-r--r-- 1 user 1896053708 1148 2 Jan 15:25 custom-resource-utils.ts
-rw-r--r-- 1 user 1896053708 870 2 Jan 15:18 delete-ddb-table-lambda.ts
-rw-r--r-- 1 user 1896053708 1401 2 Jan 14:10 create-invalid-stack-lambda.ts
Once CDK app is build, it generates cdk.out with bunch of template JSON files as well as the asset.XXX directory that is a copy of the ./lib/lambda directory.
$ ll build/cdk.out/asset.12efd52ab96c4083197e09d00af8f35f6f4f02b951217130bede554ac178685b
total 64
-rw-r--r-- 1 user 1896053708 5324 3 Jan 09:18 create-invalid-stack-lambda.js
-rw-r--r-- 1 user 1896053708 1401 3 Jan 09:18 create-invalid-stack-lambda.ts
-rw-r--r-- 1 user 1896053708 4719 3 Jan 09:18 custom-resource-utils.js
-rw-r--r-- 1 user 1896053708 1148 3 Jan 09:18 custom-resource-utils.ts
-rw-r--r-- 1 user 1896053708 3501 3 Jan 09:18 delete-ddb-table-lambda.js
-rw-r--r-- 1 user 1896053708 870 3 Jan 09:18 delete-ddb-table-lambda.ts
We can confirm that bytes sizes of files match the original files.
Then this directory gets zipped by CDK by the zipDirectory() function which, however, generates a corrupted ZIP file. I think the underlying archiver NPM module has a bug somewhere.
$ unzip -t build/cdk.out/asset.12efd52ab96c4083197e09d00af8f35f6f4f02b951217130bede554ac178685b.zip
Archive: build/cdk.out/asset.12efd52ab96c4083197e09d00af8f35f6f4f02b951217130bede554ac178685b.zip
testing: create-invalid-stack-lambda.js bad CRC 28acfbde (should be 6bd7e1c9)
file #2: bad zipfile offset (local header sig): 2731
file #3: bad zipfile offset (local header sig): 5009
file #4: bad zipfile offset (local header sig): 5771
testing: delete-ddb-table-lambda.js OK
testing: delete-ddb-table-lambda.ts OK
At least one error was detected in build/cdk.out/asset.12efd52ab96c4083197e09d00af8f35f6f4f02b951217130bede554ac178685b.zip.
When I try to force unzip locally, the following error is displayed:
Unable to expand "asset.12efd52ab96c4083197e09d00af8f35f6f4f02b951217130bede554ac178685b.zip` into "cdk.out".
The deployment to the actual stack also fails with the following error:
Could not unzip uploaded file. Please check your file, then try to upload again. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: 853d7206-2f80-422e-a7ff-01c15b960ed9)
When I check the file size, I see the following:
$ ll build/cdk.out/
-rw-r--r-- 1 user 1896053708 10218 3 Jan 09:53 asset.12efd52ab96c4083197e09d00af8f35f6f4f02b951217130bede554ac178685b - CORRECT.zip
-rw-r--r--@ 1 user 1896053708 9280 3 Jan 09:18 asset.12efd52ab96c4083197e09d00af8f35f6f4f02b951217130bede554ac178685b.zip
Note that the file size of the correct zip which I manually generated is 10KB while the actual one generated by CDK is 9KB.
@kadishmal how did you obtain the .zip file created by the CDK? It's not supposed to be under the cdk.out directory...
Any news on this issue?
I have a similar issue. When I use a zip as a source code for a Lambda, the zip that is copied to the S3 bucket is corrupt
Corrupted in what way? Can you share some details?
No response yet from the requesters. Closing.
Please re-open with more details. Thanks!
I'm getting the same issue here as well. @eladb the zip files in the cdk.out folder are just the asset.* files for me.
The error that I get from running cdk deploy MyStack is
2/5 | 1:40:29 PM | UPDATE_FAILED | AWS::Lambda::Function | Watchful/AlarmFunction (WatchfulAlarmFunction84AB3947) Could not unzip uploaded file. Please check your file, then try to upload again. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: 9b1a383e-857a-4422-a664-297df2e02b13)
The error I get then I try to run unzip cdk.out/asset.0ea27e9d503ee9ddf6c3eb85001baf39528958392bb3ebef1ec069c68450c946.zip is
Archive: cdk.out/asset.0ea27e9d503ee9ddf6c3eb85001baf39528958392bb3ebef1ec069c68450c946.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of cdk.out/asset.0ea27e9d503ee9ddf6c3eb85001baf39528958392bb3ebef1ec069c68450c946.zip or
cdk.out/asset.0ea27e9d503ee9ddf6c3eb85001baf39528958392bb3ebef1ec069c68450c946.zip.zip, and cannot find cdk.out/asset.0ea27e9d503ee9ddf6c3eb85001baf39528958392bb3ebef1ec069c68450c946.zip.ZIP, period.
I'm on aws-cdk: 1.45.0 and a Macbook Pro 10.15.4
Did you ever figure this out @seawatts @kadishmal @rubenjgarcia? One of our developers is experiencing the same error now.
We resolved the issue, the S3 bucket had corrupt files. We cleared out the entire S3 bucket of arn:aws:s3:::cdk-hiudfsaf-assets-34723248234-us-west-2 (replaced IDs in S3 folder name) and now deployments are working again.
CDK version 1.67.0 - getting the same error. Code.from_asset(path-to-a-zip-file).
In documentation it clearly states:
path (str) – Either a directory with the Lambda code bundle or a .zip file.
I can find the zip file in the assets folder of cdk bucket. Downloaded it and tried to open and indeed it fails to open. Windows says the file is invalid. Thats it.
@eladb Any thoughts on this?
With CDK 1.67, all of a sudden I got the same error when deploying from my command line to my cloud env:
Could not unzip uploaded file. Please check your file, then try to upload again. (Service: AWSLambdaInternal; Status Code: 400; Error Code: Inval
Even going back to master branch, to code that is currently deployed, I would get the same error.
I just cleaned my CDKtoolkit assets folder in S3 and then I could deploy again.
Then I went back to my new branch and was able to deploy too.
So weird.
@mattiLeBlanc
thank you saved my time :)
Most helpful comment
With CDK 1.67, all of a sudden I got the same error when deploying from my command line to my cloud env:
Could not unzip uploaded file. Please check your file, then try to upload again. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalEven going back to master branch, to code that is currently deployed, I would get the same error.
I just cleaned my CDKtoolkit assets folder in S3 and then I could deploy again.
Then I went back to my new branch and was able to deploy too.
So weird.