serverless: Lambda layer versions are not being retained

Bug Report

Description

What did you do? Deployed a layer-only service with retain: true
What happened? Previous layer version is deleted
What should’ve happened? Since retain is set to true, the previous layer version should still be available
What’s the content of your serverless.yml file?

service: config-layer
provider:
  name: aws
  profile: personal
layers:
  config:
    path: ./
    retain: true
    compatibleRuntimes:
      - nodejs10.x

What’s the output you get when you use the SLS_DEBUG=* environment variable (e.g. SLS_DEBUG=* serverless deploy) debug.txt

Similar or dependent issues:

#6010
#6532

In PR #6545, S3 key was removed from the sha hash, which results in the same logical id with every deployment. I believe cloudformation removes versions with the same logical id, regardless of DeletionPolicy: Retain being set.

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 19
Comments: 29 (4 by maintainers)

Most upvoted comments

I’m interested too, what are next steps on this?

palafoxernesto on Nov 12, 2019

Any news on this one?

danielstandby on Oct 7, 2019

Will there be any fix soon?

mregnauld on Nov 6, 2019

I am fairly new to using layers in serverless. I am quite surprised that this bug still exists. In particular, we have issues when we deploy our lambdas (using Atlassian Bamboo as our CI/CD) which depend on layers in another Cloudformation stack (centralized), and then we need to roll back the release. Since the lambda layers are not being retained, the rollback fails.

I have seen the workaround of going back to serverless 1.43.0, but I am currently on 1.60.4, so I am worried about the impact of reverting back to a version that was ages ago.

It seems we are lacking some leadership/ownership on this issue. I am not sure there is someone who can step forward and take ownership and get this fixed. I am willing to head that up if no one else is, but I am not sure I am the most qualified. It does seem like a fairly simple issue of just passing this through so that the DeletionPolicy is set to “Retain” on the Cloudformation, but I am probably oversimplifying.

mrn3 on Jan 2, 2020

Any news on this?

gustmartins on Dec 6, 2022

Can someone please explain why I should override the UpdateReplacePolicy in the Resources section instead of relying on the retain property of the layer? I’m getting an error that the stack cannot be updated because a layer ref is in use by another stack:

An error occurred: rest-api-base-stack-dev - Export RestApiBase-lambdaLayer cannot be deleted as it is in use by rest-api-users-stack-dev.

Which is the official solution?

https://github.com/serverless/serverless/issues/7353

demian85 on Apr 22, 2020

@RenatoFranze , This worked perfectly for me. Thanks!

DeekshaPandit on Mar 26, 2020

Indeed, @daninfpj , it was my mistake with the resource name. Thank you very much!

RenatoFranze on Mar 4, 2020

The CloudFormation template is invalid: Template format error: Every Resources object must contain a Type member

@RenatoFranze I think that error is unrelated to this specific issue. It’s telling you that you need to define a type for your resource.

In the example I posted, I don’t do that explicitly because the layer definition already does it, but I’m not sure if you’re doing that or if you’re referring correctly to your layer. In the example, a config entry in the layers key generates a ConfigLambdaLayer resource, that already has a Type, and I only add UpdateReplacePolicy: Retain to it.

daninfpj on Mar 3, 2020

There’s a work-around for this posted here for python-based layers

mfogel on Jan 30, 2020