(aws-lambda-nodejs): Uploaded file must be a non-empty zip #18459
Comments
apoorvmote
added
bug
|
Looks like for some (unknown) reason an empty zip file landed on S3 for this asset. It should be fixed If you manually remove the asset file from the bootstrap bucket and then retry. |
Due to something we haven't completely figured out yet, our asset packaging sometimes produces empty zip files, leading to an error like this uploading code Lambda: ``` Uploaded file must be a non-empty zip ``` Do the following to address this: * If any empty zip files already ended up in S3, do not regard this as a cache hit. Rebuild the asset and upload it again. We do this by checking the item's size: this may be overly pessimistic, but if it is we're probably not wasting a lot of time rebuilding and uploading a tiny file. * If a fresh asset build is producing an empty zip file, loudly complain and ask the user to come to our bug tracker, so we can figure out where these spurious issues are coming from. Relates to #18459.
Due to something we haven't completely figured out yet, our asset packaging sometimes produces empty zip files, leading to an error like this uploading code Lambda: ``` Uploaded file must be a non-empty zip ``` Do the following to address this: * If any empty zip files already ended up in S3, do not regard this as a cache hit. Rebuild the asset and upload it again. We do this by checking the item's size: this may be overly pessimistic, but if it is we're probably not wasting a lot of time rebuilding and uploading a tiny file. * If a fresh asset build is producing an empty zip file, loudly complain and ask the user to come to our bug tracker, so we can figure out where these spurious issues are coming from. Relates to #18459. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
peterwoodworth
added
management/tracking
|
The real issue is docker build with golang is not working. For my usecase golang lambda is still experimental. I am just keeping an eye on it for future use. I am heavily into NodeJS lambdas and they are working fine. So I just deleted single golang function and everything got deployed. Again the issue is not resolved. But golang lambda is not priority for me so I am closing this thread. |
|
Due to something we haven't completely figured out yet, our asset packaging sometimes produces empty zip files, leading to an error like this uploading code Lambda: ``` Uploaded file must be a non-empty zip ``` Do the following to address this: * If any empty zip files already ended up in S3, do not regard this as a cache hit. Rebuild the asset and upload it again. We do this by checking the item's size: this may be overly pessimistic, but if it is we're probably not wasting a lot of time rebuilding and uploading a tiny file. * If a fresh asset build is producing an empty zip file, loudly complain and ask the user to come to our bug tracker, so we can figure out where these spurious issues are coming from. Relates to aws#18459. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
In my case it was a human error. I had a CDK project with TypeScript where I had a lambda written in JavaScript. In This is my typescript code: The lambda was meant to be in Guess it would be good to have a different error/warning message there or simply fail the deployment as soon as the file cannot be found during compilation. |
|
I'm seeing this issue when trying to upgrade to CDK v2. assets.json file: My cdk.out directory: So the asset files are certainly in the |
|
Assets and directory structure are identical (excluding hashes) with CDK v1. Seems to have been an issue introduced in v2? The error output would imply to me that there's something wrong with how the zip path is being given somewhere, but the verbose output didn't give much additional insight on that. |
|
his does appear to be the result of some pathing assumptions. In our setup, we bundle cdk.out and deploy it separately from where it was synthesized. I get this error when doing that, but not if I deploy from the same place I ran synth. |
|
Reopening issue for visibility and tracking |
|
So I originally thought this issue was exclusive to CDK v2, but it turns out that this is not the case. We hadn't seen it prior to the migration because assets were being cached. This issue is blocking us from doing any deployments to new environments. |
|
Based on my testing, the issue was introduced between v1.133.0 and v1.139.0 |
|
Is there a way to disable all asset caching? Is the easiest way to handle this to delete the CDK bootstrap stack as well and recreate it? If I deploy with a good version, destroy my stack, then deploy a bad version, it will still succeed. I can only reproduce the issue with a newly bootstrapped account which is a pain in the ass to debug... |
|
This appears to be a result of the So I guess the question is: is this a bug or is this intended behavior with poor error messaging? |
|
For reference, when |
|
This will probably be my last update here. The asset code is abstracted down so many levels it's head spinning to try and understand what it is actually doing and there's little to no documentation on its internals. Here's what I've gathered: the Without any comments from the maintainers, it's hard to say if this behavior is expected or not, whether it should be fixed, or whether to add clearer messaging on the effects. I'd be happy to make any one of these changes, but I need to know that this is something the CDK team is interested in seeing fixed before I dedicate more time to this. |
|
I think I know why this is happening for my specific case. I found this occurring (as in the error showing but then the deploy succeeding) when I was using the code My explanation for why it's occurring is the I am not using zip files just plain old directory reference to |
|
Got the OS: Linux (WSL2) 5.10.102.1-microsoft-standard-WSL2 x86_64 - Ubuntu 20.04.4 LTS We're using the Expecting the built Finally, I don't think this is reproducible, as I said it's a hit and miss when it happens. Let me know if I can provide any other info or help with troubleshooting. |
|
I get this error (🚨 WARNING: EMPTY ZIP FILE 🚨) when trying to bootstrap a Golang package and upload lambda assets to s3. Is the golang issue mentioned in the beginning of this thread still not resolved? What are some workarounds? MacOS Monterey 12.3.1 I even tried by removing build/cdk.out directory |
|
Same here MacOS Monterey 12.3.1 My Python Code does not get bundled even thogh I have a |
|
Interesting. I just got this running our ecs integration tests. |
|
I'm not sure if it's due to some sort of restructure, but this issue has become far more prevalent in the last week or so, around the same time as we updated cdk to It's gone from happening ~2 times a week to 3 times a day, (deploying 10-30 times a day). There is no rhyme or reason as to why this is occurring, and a re-deploy always resolves the issue, not need to delete any cache files. |
|
This occurred for me using an internal build system (@quaeler) in which my CDK package built a lambda supplied by another package; both packages were in my local workspace, however the lambda package had been built clean and not built since. Despite the |
|
Also encountered the error (🚨 WARNING: EMPTY ZIP FILE 🚨) now while performing OS: MacOS Catalina 10.15.7 |
|
Just got it again on my machine. Removing Mac OS 12.5.1 |
|
I have issues today. my docker service (On windows) frozen and non responsive, the lambda packaging produce a empty zip file. i have to clean the cdk.out and reboot my pc to get everything work again |
|
Ok, I've narrowed down what's causing this for me. Whenever I cancel a deployment for a stack (ctrl-c), the next time I deploy and it gets to that step, ~15% of the time I'll get this error. Redoing the deployment always resolves the issue. I've noticed this to be the case every time I've see it happen over the last two weeks. |
|
Happened for the first time, then immediately again. CDK out was very full (like 4gb). Windows 11, latest update. After first instance I cleared out the cdk folder per the instructions (worth noting it hung at 99% for two minutes despite the folder being empty) , resynthed and deployed and it failed again. It failed again, I let it run that time, and it did in fact fail. Issue persisted after a restart. Fully deleting the cdk.out folder, and not merely it's contents (in case an invisible folder hung around), and recreating did not solve it. Just running the deploy again without any of the inbetween steps did nothing also. The issue occurred about six times in a row before I just gave up for the night since I'm like 4 hours over the work day anyway. |
|
@abury Was the same in my case. So far the issue has only occurred after I have canceled a deployment before. |
Here's a possible scenario that can lead to "Uploaded file must be a non-empty zip": - Bundling starts - A partial zip file is written - The process is interrupted (`^C` or similar) while writing. - On next run, the destination file already exists, is taken to be complete, and uploaded. In this fix, we'll write the zip to a temporary file and atomically rename it into place once finished, thereby avoiding this possible scenario. Attempts to fix #18459.
#22393) Here's a possible scenario that can lead to "Uploaded file must be a non-empty zip": - Bundling starts - A partial zip file is written - The process is interrupted (`^C` or similar) while writing. - On next run, the destination file already exists, is taken to be complete, and uploaded. In this fix, we'll write the zip to a temporary file and atomically rename it into place once finished, thereby avoiding this possible scenario. Attempts to fix #18459. I don't have tests for this, I don't know how to write them properly. To my mind, if the code looks good and we pass integration tests, that should be sufficient. Add a global asset salting mechanism so that we know all asset hashes are always unique. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
aws#22393) Here's a possible scenario that can lead to "Uploaded file must be a non-empty zip": - Bundling starts - A partial zip file is written - The process is interrupted (`^C` or similar) while writing. - On next run, the destination file already exists, is taken to be complete, and uploaded. In this fix, we'll write the zip to a temporary file and atomically rename it into place once finished, thereby avoiding this possible scenario. Attempts to fix aws#18459. I don't have tests for this, I don't know how to write them properly. To my mind, if the code looks good and we pass integration tests, that should be sufficient. Add a global asset salting mechanism so that we know all asset hashes are always unique. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Ubuntu 20.04 asset was supposed to contain a lambda function. i thaught I caused it because of a recently emptied sub directory. git diff has revealed that the change causing this to happen was : I was creating a dependencies layer (by installing with pip into a directory and adding it as a lambda layer) for a function with an empty dependencies file. removing the empty requirements file and conditioning the layer on finding it in the lambda directory fixed the issue for me. |
|
Has this issue been really closed? I am getting the following error in the Assets step my of code pipeline. The same code works fine when I deploy locally via
The build project runs on |
Yeah I'm definitely still seeing this issue in development. Totally get it's a really tough one to solve, but it might need to be re-opened sadly. |
@abury Just got mine fixed. I had to update the CDK CLI version to 2.46.0 (or newer). |
|
In my case it was human error, too. My handler function had a non-default name (i.e., not A more precise error message in this case would be useful. For example: "No export 'handler' found in entry file". |
aws#22393) Here's a possible scenario that can lead to "Uploaded file must be a non-empty zip": - Bundling starts - A partial zip file is written - The process is interrupted (`^C` or similar) while writing. - On next run, the destination file already exists, is taken to be complete, and uploaded. In this fix, we'll write the zip to a temporary file and atomically rename it into place once finished, thereby avoiding this possible scenario. Attempts to fix aws#18459. I don't have tests for this, I don't know how to write them properly. To my mind, if the code looks good and we pass integration tests, that should be sufficient. Add a global asset salting mechanism so that we know all asset hashes are always unique. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
In my case it was a misplacement of the lambda//Handler class file. The error message should be more specific! |
|
Consistently running into this problem without even having cancelled a build as others have mentioned. Deleting Windows 11 I'm trying to use a basic Nodejs function construct and I've confirmed that the docker container does build the code correctly. Narrowed the problem down to what I think is trouble zipping the asset output on specifically WSL, as it runs fine from Powershell. Running CDK in verbose mode doesn't lead to anything that sheds light on why it would fail. So, TLDR for those still running into this: |
|
In my case, the CodeUri of the function pointed to the wrong directory. |
|
I was getting the same error and I managed to solve it for my particular case. Stack: Events (possibly) leading to my issue:
Steps to fix my issue:
Note: Possibly, a subset of the five steps listed above might be sufficient to resolve the issue. |
|
After a successful deployment we ran into this error and noticed that the code wasn't being bundled, we simply removed |
and others
What is the problem?
I updated lambda function dependancies and deploying the lambda function but it fails with following error.
I also have another api under the same project and I updated its lambda function dependancies and it was deployed successfully.
Both api's and its lambda functions are almost identical to each other. However only one gets deployed and another one doesn't.
I deleted the
cdk.outfolder and tried to deploy again and it fails with same error each time.Reproduction Steps
I have simple lambda function that I am trying to deploy as follows
What did you expect to happen?
I expected it to deploy all of my lambda functions.
What actually happened?
It failed with error
Uploaded file must be a non-empty zipCDK CLI Version
2.8.0
Framework Version
No response
Node.js Version
v16.13.2
OS
Ubuntu 20.04 on WSL 2
Language
Typescript
Language Version
~3.9.7
Other information
No response
The text was updated successfully, but these errors were encountered: