Hello @ifanchu, thanks for reporting. Did you first build your go binary? Serverless Framework won't run the go build step and if you don't build it first, there will be nothing to be packed into zip artifact.

I have the same issue since yesterday as well. I've spent the evening trying to figure it out thinking it was a problem on my laptop. I've rebooted countless times, removed and installed Serverless again countless times, I've checked my firewall rules in case it was preventing file upload but that was not it. I also checked the uploaded zip into s3, the files were there but were all empty with 0 bytes size..

running sls package produces a compressed zip with the right files and size
running sls deploy procudes and uploads a zip with the right files but all empty

I'm actually glad I'm not the only one having this issue.

I'm on Mac Os Big Sur running latest everything (node, npm, docker, Brew...)

$ sls --version
Framework Core: 2.19.0
Plugin: 4.4.2
SDK: 2.3.2
Components: 3.4.7

Serverless Yaml content

# Happy Coding!

service: new-challenge-event
frameworkVersion: '2'

provider:
  name: aws
  runtime: nodejs12.x
  region: us-east-1
  stage: dev
  lambdaHashingVersion: 20201221
  versionFunctions: false # optional, default is true

functions:
  process:
    handler: handler.process
    description: dispatches event when new challenge is created
    reservedConcurrency: 5
    memorySize: 256
    timeout: 2
    events:
      - stream:
          type: dynamodb
          arn:
            arn:xxx
          batchSize: 1

I'm having the exact same issue today with code that was working perfectly before. I'm working with serverless 2.19.0 but I've also downgraded to 2.18.0

I'm testing with a Python lambda function, even a simple hello world function won't deploy with the following error

Uploaded file must be a non-empty zip (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException;

Hello @ifanchu, thanks for reporting. Did you first build your go binary? Serverless Framework won't run the go build step and if you don't build it first, there will be nothing to be packed into zip artifact.

yes I did, and as I mentioned, I tried sls package and size of myservice is

-rw-r--r--  1 ifanchu  staff   6.1M Jan 15 23:57 myservice.zip

Then I tried to unzip it

> unzip myservice.zip
Archive:  myservice.zip
  inflating: bin/hello                bad CRC 27b2eaa3  (should be 00000000)
  inflating: bin/world                bad CRC dd4840b8  (should be 00000000)

> ls -ltrh bin
total 28464
-rwxr-xr-x  1 ifanchu  staff   6.9M Jan  1  1980 world
-rwxr-xr-x  1 ifanchu  staff   6.9M Jan  1  1980 hello

Looks a little weird to me...

i'm having the same issue, tested on fresh osx and debian 10 with nodejs helloworld example. got the same error

  Your Environment Information ---------------------------
     Operating System:          darwin
     Node Version:              15.6.0
     Framework Version:         2.19.0
     Plugin Version:            4.4.2
     SDK Version:               2.3.2
     Components Version:        3.4.7

service: helloworld
frameworkVersion: '2'

provider:
  name: aws
  runtime: nodejs12.x
  lambdaHashingVersion: 20201221

functions:
  hello:
    handler: handler.hello

Hello @ifanchu, thanks for reporting. Did you first build your go binary? Serverless Framework won't run the go build step and if you don't build it first, there will be nothing to be packed into zip artifact.

I ran make build which builds bin/hello and bin/world.

Hello everyone - thanks a lot for reporting more details about the issue. I've had a hard time reproducing it, but seeing output from @lxwang42 I've noticed use of the latest version of node v15.6.0 and in fact, I was able to reproduce the issue on both framework versions v2.18.0 and v2.19.0. Surprisingly, when going back to node v14 or even to v15.5.0, the problem does not exist (or at least I wasn't able to reproduce). It seems like the packaged zips are broken as when even trying to unzip them locally they error out with bad CRC as was also shown by @ifanchu.

The question to everyone reporting - are you all on node v15.6.0 or is there anyone that experiences the same issue with different node versions? I tried v10, v12, v14, v15.5.0 and could not reproduce. For now, I'll continue the investigation under the assumption that issue is present only on the v15.6.0 of node.

Thanks everyone for detailed reports 🙇

I was on v15.6.0

╰─➤  node --version
v15.6.0

I downgraded to

╰─➤  node -v
v14.15.4
╰─➤  npm -v
6.14.10

And it is working good now.

I created a small reproducer repository. See the Github action and the latest output.

I've tested with Node 15.5 and it is working. It seams to be broken only on 15.6.

I can also confirm I was running Node v15.6.0 and when I rolled back to Node v14.15.1 all is working fine so it seems to be Node related

Confirmed working with node@14

Thanks everyone for checking out and confirming that it's in fact related to node v15.6.0. I've managed to pinpoint the issue to the library that we're using to create zip archives - archiverjs/node-archiver#491. I'll be tracking the issue and make sure to let everyone here know as soon as we have a resolution. 💯

I can also confirm I was running Node v15.6.0 and when I rolled back to Node v14.15.1 all is working fine so it seems to be Node related

I've had to roll back as well from v15.6.0 and v14.15.1 worked.

@pgrzesik I can confirm this is working on node v15.5.x as well.

I don't know what the timeline for the fix upstream is, it might not be a bad idea to set engines via a hotfix for now.
Thanks for the heads-up earlier!

To let everyone know, it has been confirmed to be a Node issue: nodejs/node#37027

This is still broken on 15.7.0.. however can confirm it works if downgrading to 14.15.1

Confirmed rolling back from node @ 15.6.0 to 14.15.4 fixed the problem for me.

How can i downgrade the node version? Please...

@bssilveira91 - that depends on the installation method for Node, one of the options is to use nvm (https://github.com/nvm-sh/nvm). Alternatively, you can also use a standalone version of the Framework to be independent of installed Node version: https://www.serverless.com/framework/docs/getting-started#install-as-a-standalone-binary

@bssilveira91 here hints shared by @sphinxs

Same issue with node 15, downgrade to node 14 works.

Hello everyone 👋 The original issue has been resolved and new version of crc32-stream has been published. All new serverless installations should use that version by default. I'm closing this issue, but if you're still running into errors please let us know 🙇

How does one make an existing serverless project use this new version?

Hello @electric-al - the best way is to just do a fresh installation which will install a patched version of crc32-stream dependency

@pgrzesik , is this the place where the last run times are published?

Hello @sphinxs - I believe it's an obsolete page - also, what do you mean by last run times?

Hello @sphinxs - I believe it's an obsolete page - also, what do you mean by last run times?

I mean the supported languages and the versions, eg. Node 14, Python 3.9...

Thanks for the clarification - all languages and versions supported by AWS are supported by Serverless Framework

node v16 - same issue...
fixed by overriding crc32-stream version by:

"resolutions": {
    "crc32-stream": "4.0.2"
}

in package.json