Issues when parallel deploy triggers `serverless` auto-update?

[mnapoli]

I got this error today and I think it's caused by the auto-update triggering multiple times in parallel. The output is incomplete because of the CLI redraw, but I have multiple services deploying in parallel:

❯ sls4 deploy

Deploying to stage dev
        ^

[Error: ENOENT: no such file or directory, rename '/var/folders/jm/9b4283151yj9y3np80n1d2mw0000gn/T/tmpdirs-serverless/npm-update-3.4.0' -> '/opt/homebrew/lib/node_modules/serverless'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'rename',
  path: '/var/folders/jm/9b4283151yj9y3np80n1d2mw0000gn/T/tmpdirs-serverless/npm-update-3.4.0',
  dest: '/opt/homebrew/lib/node_modules/serverless'
}

Node.js v17.4.0

    ✖  users › error › 145s

Error:
Error: Cannot find module '../../../../lib/get-service-state'
Require stack:
- /opt/homebrew/lib/node_modules/serverless/lib/plugins/aws/package/compile/events/api-gateway/index.js
- /opt/homebrew/lib/node_modules/serverless/lib/plugins/index.js
- /opt/homebrew/lib/node_modules/serverless/lib/classes/plugin-manager.js
- /opt/homebrew/lib/node_modules/serverless/lib/serverless.js
- /opt/homebrew/lib/node_modules/serverless/scripts/serverless.js
- /opt/homebrew/lib/node_modules/serverless/bin/serverless.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at after:deploy:deploy (/opt/homebrew/lib/node_modules/serverless/lib/plugins/aws/package/compile/events/api-gateway/index.js:263:33)
    at PluginManager.runHooks (/opt/homebrew/lib/node_modules/serverless/lib/classes/plugin-manager.js:522:41)
    at async PluginManager.invoke (/opt/homebrew/lib/node_modules/serverless/lib/classes/plugin-manager.js:553:9)
    at async PluginManager.run (/opt/homebrew/lib/node_modules/serverless/lib/classes/plugin-manager.js:592:7)
    at async Serverless.run (/opt/homebrew/lib/node_modules/serverless/lib/serverless.js:169:5)
    at async /opt/homebrew/lib/node_modules/serverless/scripts/serverless.js:686:9

I had to manually reinstall serverless after that because the CLI did not exist anymore.

If that's indeed it, I'm not sure what's the best course of action. Would silencing auto-update errors in SF be enough?

[pgrzesik]

I didn't run into it yet but it is a problem, indeed. Silencing error isn't really a solution I think, because all the update operations will trigger anyway multiple times if CLI is run in parallel. I think we will have to do one of the following:

• Enforce to disable auto-update when running with components (does not sound great, because we want people to update)
• Run some dummy command first to check if autoupdate is available (also doesn't sound great because we don't want any extra stuff running before each other command)
• Rely on direct integration with serverless cli, which would handle the autoupdate operation

[mnapoli]

Rely on direct integration with serverless cli, which would handle the autoupdate operation

Oh good point, since this is our goal eventually auto-update will happen in the root command. We just need to make sure it isn't triggered in sub-commands (because it's useless), and we could implement that right now to avoid the problem while we still have an independent CLI. Is there an environment variable we can set to disable autoupdating?

[pgrzesik]

At the moment we don't have such a variable - we would have to add it to the Framework

[pgrzesik]

Hello @mnapoli - ahead of our upcoming public beta, it seems like something that might become an issue sooner or later - should we move it up on the list of our priorities and find out a potential solution for it?

[mnapoli]

@pgrzesik I forgot about that from our discussion this morning. Yes, it would be great to solve that.

Should we introduce an env variable in Serverless Framework to disable auto-updates? Do you see a better alternative?

[pgrzesik]

I forgot to mention it as well when we talked today 🤦 I think the lowest-effort solution would be to introduce an env variable for that in the Framework. It is also possible to ask people to disable autoupdates globally in a manual way, but I think it's a worse solution because it discourages updates in general for users and requires an additional manual step for them.

[mnapoli]

OK I'll add that to the TODO list 👍