serverless: function "..." you want to update is not yet deployed

This is a Bug Report

Description

Saw function "loadGenerator" you want to update is not yet deployed... when trying to deploy previously working service.

I have been able to reproduce this using the latest in NPM (v1.21.1) but not with a branch off of master (circular-vars). Still investigating cause and will try to update if I discover anything.

For bug reports:

What went wrong? ‘ServerlessError: The function “loadGenerator” you want to update is not yet deployed. Please run “serverless deploy” to deploy your service. After that you can redeploy your services functions with the “serverless deploy function” command.’
What did you expect should have happened? Successful deployment, as usual
What was the config you used? see https://github.com/Nordstrom/serverless-artillery/blob/master/lib/lambda/serverless.yml
What stacktrace or error message from your provider did you see? See stack trace at tail.

Similar or dependent issues:

https://github.com/Nordstrom/serverless-artillery/issues/76 (original report of issue, investigating…)

Additional Data

Serverless Framework Version you’re using: 1.21.1
Operating System: OSx
Stack Trace:

$ npm i -g serverless serverless-artillery
$ serverless-artillery deploy

        Deploying Lambda to AWS...

{ ServerlessError: The function "loadGenerator" you want to update is not yet deployed. Please run "serverless deploy" to deploy your service. After that you can redeploy your services functions with the "serverless deploy function" command.
    at provider.request.then.catch (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/lib/plugins/aws/deployFunction/index.js:65:13)
    at tryCatcher (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/node_modules/bluebird/js/release/promise.js:689:18)
    at Async._drainQueue (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/node_modules/bluebird/js/release/async.js:133:16)
    at Async._drainQueues (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/node_modules/bluebird/js/release/async.js:143:10)
    at Immediate.Async.drainQueues (~/.nvm/versions/node/v6.11.0/lib/node_modules/serverless/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:672:20)
    at tryOnImmediate (timers.js:645:5)
    at processImmediate [as _immediateCallback] (timers.js:617:5) name: 'ServerlessError', statusCode: undefined }

        Deploy complete.

Provider Error messages: N/A

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (16 by maintainers)

Most upvoted comments

I’m really happy to read this @pmuens, thanks for the update!

erikerikson on Sep 13, 2017

Thanks for the discussion and the analysis on the serverless-artillery project @erikerikson and @HyperBrain 👍

We’re very sorry for this bug to pop up (and opening this issue here was definitely not noise, so keep it coming 😃).

We’ve completely abandoned planned breaking changes a long time ago and started to follow server again (we’ve created the VERSIONING.md file to have a contract on that with our community). However as @HyperBrain mentioned we’re not following it strictly here.

The root cause for this is our release process right now. As soon as we’ve released a new version we start to review and merge new PRs. However if there’s a bug which should be fixed ASAP (in the case for this release it was the bug that binary data is not packaged correctly) we simply publish a patch release which might include recent merges as well. IMHO we should cherry-pick the bug fix and only publish that, but that’s something we need to discuss (maybe in a separate issue).

Again. Thanks for bringing this up and thanks for the in-depth discussion on that 👍

pmuens on Sep 13, 2017

@pmuens Regarding Frank’s missive on strong semver, I couldn’t be more supportive. This is a challenge for us and it leads to negative experiences for our workshops, engineers, and public parties. This reduces adoption and “those magic moments”

A quick way to accomplish this (and another goal) would be to make serverless programmatically usable and then have a thin shim that manages/contains/maintains the product version while allowing the implementation module to iterate on the major version for reliable usage.

Personally, so I’m perfectly happy to have to update versions and keep up so long as previously working and reliable setups aren’t being broken without notice. Maybe we need to cron our builds to detect this stuff. That’s the alternative before us given the behavior and choices so far with serverless.

erikerikson on Sep 12, 2017

Thanks for the in-depth explanation here @HyperBrain 👍

Yes, I agree. It’s an additive feature and therefore non-breaking (if we’ve followed semver correctly).

@erikerikson is correct that it’s a breaking change in this specific case because we shipped it with a patch release. We definitely need to revisit our release process here (shipping minor features in a patch release is a no-go).

/cc @brianneisler @eahefnawy 🔝

pmuens on Sep 12, 2017