Serverless hangs on "Removing old artifacts..."

[abagshaw]

First off, awesome plugin. This is so much easier to use than serverless-webpack to get the async/await functionality I need.

One odd issue I encountered: When using serverless deploy everything works as expected up to and including successfully deploying the function, but after that I get:

Serverless: Removing old artifacts...

And it hangs permanently on that. I'm on Win 10 deploying to Google Cloud Functions if that makes any difference. I tried enabling logs with setting the SLS_DEBUG env variable to * but I didn't see anything new outputted - maybe I'm supposed to be looking somewhere else?

When not using the serverless-async-await plugin, the Removing old artifacts... step completes successfully in a second or two.

Any ideas? Thanks very much!

[kuashe]

I managed to reproduce the issue only if there is no handler specified in the serverless.yml

Is this an old or a fresh service ?

Also can you try to npm update the plugin and serverless as well ?

[abagshaw]

I tried creating a new service, re-installing serverless globally and freshly installing the plugin locally but it still hangs, but oddly now it hangs just before showing Serverless: Removing old artifacts... (right after showing the URL trigger of the function)

If it's of any help, here are my configuration files:

serverless.yml:

service: user-manage-function

provider:
  name: google
  runtime: nodejs
  project: firstproject
  credentials: keyfile.json

plugins:
  - serverless-google-cloudfunctions
  - serverless-async-await

package:
  exclude:
    - node_modules/**
    - .gitignore
    - .git/**

functions:
  first:
    handler: mainHandler
    events:
      - http: user-manage-function

package.json:

{
  "name": "user-manage-function",
  "version": "0.1.0",
  "description": "",
  "main": "index.js",
  "dependencies": {
    "serverless-google-cloudfunctions": "^1.1.1",
    "@google/cloud-debug": "latest"
  },
  "devDependencies": {
    "serverless-async-await": "^1.1.4"
  }
}

[abagshaw]

My best guess is that the problem lies in waitForFiles(). I'm very unfamiliar with the serverless framework and how this plugin has been written, but it appears that the application will be hung up until exactly 4 files are found in the /__build__/.serverless/ folder. In my case only 3 files show up:

configuration-template-create.yml configuration-template-update.yml user-manage-function.zip

So I can understand why this hangs. What is the fourth file that is expected and why is it necessary to wait for the right number of files - does serverless continue modifying the contents of that folder after the after:deploy:function:packageFunction hook has been called?

[kuashe]

You are totally right. The waitForFiles expect to have four file is the zip folder .

Again if there is no handler specified serverless does not create a zip and it hangs for ever .

I'm might need to fix this next update .

[kuashe]

Also this is indeed waitForFiles the method expect 4 files and when Google Cloud is set as provider only 1 . I may fix this this weekend.

[abagshaw]

Ok, well 3 files show up when Google Cloud is set as the provider...at least in my case (as I listed above). You mentioned that the fourth file it expects is the .zip - but I do have a .zip show up as I listed above so I don't think that's the missing file.

Just wondering though, why have you implemented the waitForFiles feature - did you find by experimenting that serverless keeps modifying files in that folder after the after:deploy:function:packageFunction hook has been called? If so, is there a later hook that could be used so that we don't have to wait for files to show up?

It seems like it will be prone to more errors in the future if a new provider is added that produces a different number of files - or if the number of files produced by an existing provider changes.

[kuashe]

After the hook , i find situation where the files would still not be there and I had to wait a few milliseconds before they would be "copyable" by the system. Probably due to usage of synchronous methods.

For Google when running sls package i had only a zip in .serverless i guess i need to had the plugin as well to produce the correct output.

Yes this is limit regarding changes in framework and toward provider, but honnestly beyond AWS , Google and Microsoft not many providers will use this framework they'll tend to use their own framework. I wont bother with IBM Openwhisk or others.

I'm going to inspect the output of Google and Azure to make sure it works for these two.